Announce: ghc-core, command line pager for reading GHC Core

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Announce: ghc-core, command line pager for reading GHC Core

Don Stewart-2
Just a quick announcement, I've uploaded to hackage 'ghc-core' , a
wrapper over ghc for displaying the optimised core and assembly language
ghc produces from your programs.

The code is colourised by hscolour, and displayed in a pager, git-log style.

This will be useful for those who like looking at optimised Haskell.

You can quickly get an idea of what kind of core and assembly your code
is turning into, and the effect of various flags on the result.

Usage:

   $ ghc-core Foo.hs
   $ ghc-core Foo.hs -optc-O2 -fvia-C

Get it here,

    http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-core

Screenshot,

    http://galois.com/~dons/images/ghc-core.png

Cheers,
  Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Announce: ghc-core, command line pager for reading GHC Core

Neil Mitchell
Hi Don,

> Just a quick announcement, I've uploaded to hackage 'ghc-core' , a
>  wrapper over ghc for displaying the optimised core and assembly language
>  ghc produces from your programs.

This is cool, but it still lags behind the facilities found in yhc-core.

http://yhc06.blogspot.com/2006/12/yhccorehtml.html

I have found that any effort put into improving Core viewing tools
repays itself rather quickly, and that HTML output with hyperlinks is
incredibly handy!

Thanks

Neil
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Announce: ghc-core, command line pager for reading GHC Core

Henning Thielemann

On Fri, 2 May 2008, Neil Mitchell wrote:

> Hi Don,
>
>> Just a quick announcement, I've uploaded to hackage 'ghc-core' , a
>>  wrapper over ghc for displaying the optimised core and assembly language
>>  ghc produces from your programs.
>
> This is cool, but it still lags behind the facilities found in yhc-core.
>
> http://yhc06.blogspot.com/2006/12/yhccorehtml.html
>
> I have found that any effort put into improving Core viewing tools
> repays itself rather quickly, and that HTML output with hyperlinks is
> incredibly handy!

I have tried ghc-core now. I find the idea really good to make Core more
readable, but although my examples are moderately small the Core already
spans several pages. Thus highlighting alone is of limitted help. Indeed,
if the output would be HTML as Neil proposed, this would be cool. Then I
could quickly find out, what value 'lit_r3gZ' refers to.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Announce: ghc-core, command line pager for reading GHC Core

Henning Thielemann
In reply to this post by Neil Mitchell

On Fri, 2 May 2008, Neil Mitchell wrote:

> Hi Don,
>
>> Just a quick announcement, I've uploaded to hackage 'ghc-core' , a
>>  wrapper over ghc for displaying the optimised core and assembly language
>>  ghc produces from your programs.
>
> This is cool, but it still lags behind the facilities found in yhc-core.
>
> http://yhc06.blogspot.com/2006/12/yhccorehtml.html
>
> I have found that any effort put into improving Core viewing tools
> repays itself rather quickly, and that HTML output with hyperlinks is
> incredibly handy!

  An even more advanced tool could show differences between two Core
listings. Say I have a program which runs too slow. But if I change a
small detail it runs significantly faster - I want to know, how did my
change in the Haskell file modified the Core and why the speedup.
  Showing differences between Core files will certainly be complicated
because the generated identifiers are completely different. I don't know
whether the order of declarations is a problem.

  I have an example here where a program becomes faster by a factor of 10
with a rather small change. First I thought the slow thing must be the
higher order function which occurs in the Core and is not inlined, but it
is present in the slow and the fast variant of the program.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Announce: ghc-core, command line pager for reading GHC Core

Henning Thielemann

On Fri, 23 May 2008, Henning Thielemann wrote:

> An even more advanced tool could show differences between two Core listings.
> Say I have a program which runs too slow. But if I change a small detail it
> runs significantly faster - I want to know, how did my change in the Haskell
> file modified the Core and why the speedup.
> Showing differences between Core files will certainly be complicated because
> the generated identifiers are completely different. I don't know whether the
> order of declarations is a problem.
>
> I have an example here where a program becomes faster by a factor of 10 with
> a rather small change. First I thought the slow thing must be the higher
> order function which occurs in the Core and is not inlined, but it is present
> in the slow and the fast variant of the program.

In this special example, actually simple 'diff' spotted the critical
difference, namely a polymorphic function was called. Now I'm in a
dilemma: I can either INLINE the function, then it's whole body is copied
into main program, which is not necessary here. However this solution
would guarantee speed in every case. Or I can SPECIALISE the function,
then the function will only be called, but with polymorphism overhead
eliminated. This would only work for a restricted range of types. I'd like
to have a pragma, that tells GHC to specialise a function for every type
it is called with.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Announce: ghc-core, command line pager for reading GHC Core

Ian Lynagh
In reply to this post by Henning Thielemann
On Fri, May 23, 2008 at 05:54:36PM +0200, Henning Thielemann wrote:
>
>  An even more advanced tool could show differences between two Core
> listings.

That would be great. In the meantime, from GHC 6.10,
    -ddump-simpl -dsuppress-uniques
can be good enough to get by (it means you don't get different random
names, so diff more-or-less works).


Thanks
Ian

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Announce: ghc-core, command line pager for reading GHC Core

Don Stewart-2
In reply to this post by Henning Thielemann
lemming:

>
> On Fri, 23 May 2008, Henning Thielemann wrote:
>
> >An even more advanced tool could show differences between two Core
> >listings. Say I have a program which runs too slow. But if I change a
> >small detail it runs significantly faster - I want to know, how did my
> >change in the Haskell file modified the Core and why the speedup.
> >Showing differences between Core files will certainly be complicated
> >because the generated identifiers are completely different. I don't know
> >whether the order of declarations is a problem.
> >
> >I have an example here where a program becomes faster by a factor of 10
> >with a rather small change. First I thought the slow thing must be the
> >higher order function which occurs in the Core and is not inlined, but it
> >is present in the slow and the fast variant of the program.
>
> In this special example, actually simple 'diff' spotted the critical
> difference, namely a polymorphic function was called. Now I'm in a
> dilemma: I can either INLINE the function, then it's whole body is copied
> into main program, which is not necessary here. However this solution
> would guarantee speed in every case. Or I can SPECIALISE the function,
> then the function will only be called, but with polymorphism overhead
> eliminated. This would only work for a restricted range of types. I'd like
> to have a pragma, that tells GHC to specialise a function for every type
> it is called with.
>

I usually go with inlining, and get GHC as a whole program optimising compiler.

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[2]: Announce: ghc-core, command line pager for reading GHC Core

Bulat Ziganshin-2
In reply to this post by Henning Thielemann
Hello Henning,

Friday, May 23, 2008, 8:31:24 PM, you wrote:

> would guarantee speed in every case. Or I can SPECIALISE the function,
> then the function will only be called, but with polymorphism overhead
> eliminated. This would only work for a restricted range of types. I'd like
> to have a pragma, that tells GHC to specialise a function for every type
> it is called with.

me too. btw, this already present in jhc. inlining doesn't work in any
complex case since recursive functions can't be inlined


--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Announce: ghc-core, command line pager for reading GHC Core

Don Stewart-2
In reply to this post by Ian Lynagh
igloo:

> On Fri, May 23, 2008 at 05:54:36PM +0200, Henning Thielemann wrote:
> >
> >  An even more advanced tool could show differences between two Core
> > listings.
>
> That would be great. In the meantime, from GHC 6.10,
>     -ddump-simpl -dsuppress-uniques
> can be good enough to get by (it means you don't get different random
> names, so diff more-or-less works).
>

Great! That's easier than doing the renaming on the tool side.

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[2]: Announce: ghc-core, command line pager for reading GHC Core

Henning Thielemann
In reply to this post by Bulat Ziganshin-2

On Fri, 23 May 2008, Bulat Ziganshin wrote:

> Hello Henning,
>
> Friday, May 23, 2008, 8:31:24 PM, you wrote:
>
>> would guarantee speed in every case. Or I can SPECIALISE the function,
>> then the function will only be called, but with polymorphism overhead
>> eliminated. This would only work for a restricted range of types. I'd like
>> to have a pragma, that tells GHC to specialise a function for every type
>> it is called with.
>
> me too. btw, this already present in jhc. inlining doesn't work in any
> complex case since recursive functions can't be inlined

GHC inlines recursive functions, too, otherwise it could not turn 'foldl'
and friends into plain machine loops.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: Announce: ghc-core, command line pager for reading GHC Core

Duncan Coutts

On Fri, 2008-05-23 at 21:24 +0200, Henning Thielemann wrote:

> On Fri, 23 May 2008, Bulat Ziganshin wrote:
>
> > Hello Henning,
> >
> > Friday, May 23, 2008, 8:31:24 PM, you wrote:
> >
> >> would guarantee speed in every case. Or I can SPECIALISE the function,
> >> then the function will only be called, but with polymorphism overhead
> >> eliminated. This would only work for a restricted range of types. I'd like
> >> to have a pragma, that tells GHC to specialise a function for every type
> >> it is called with.
> >
> > me too. btw, this already present in jhc. inlining doesn't work in any
> > complex case since recursive functions can't be inlined
>
> GHC inlines recursive functions, too, otherwise it could not turn 'foldl'
> and friends into plain machine loops.

Actually ghc's definition of foldl is not recursive, though it does of
course contain a local recursion:

foldl        :: (a -> b -> a) -> a -> [b] -> a
foldl f z xs = lgo z xs
             where
                lgo z []     =  z
                lgo z (x:xs) = lgo (f z x) xs

The lgo recursive call is then specialised at the call site and we can
get good code.

As I understand it, if foldl was written in the standard directly way
then ghc would not inline it. So we have to manually apply the static
argument transformation. You'll see that foldr is written in the same
way.

Duncan



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: Announce: ghc-core, command line pager for reading GHC Core

Don Stewart-2
duncan.coutts:

>
> On Fri, 2008-05-23 at 21:24 +0200, Henning Thielemann wrote:
> > On Fri, 23 May 2008, Bulat Ziganshin wrote:
> >
> > > Hello Henning,
> > >
> > > Friday, May 23, 2008, 8:31:24 PM, you wrote:
> > >
> > >> would guarantee speed in every case. Or I can SPECIALISE the function,
> > >> then the function will only be called, but with polymorphism overhead
> > >> eliminated. This would only work for a restricted range of types. I'd like
> > >> to have a pragma, that tells GHC to specialise a function for every type
> > >> it is called with.
> > >
> > > me too. btw, this already present in jhc. inlining doesn't work in any
> > > complex case since recursive functions can't be inlined
> >
> > GHC inlines recursive functions, too, otherwise it could not turn 'foldl'
> > and friends into plain machine loops.
>
> Actually ghc's definition of foldl is not recursive, though it does of
> course contain a local recursion:
>
> foldl        :: (a -> b -> a) -> a -> [b] -> a
> foldl f z xs = lgo z xs
>              where
>                 lgo z []     =  z
>                 lgo z (x:xs) = lgo (f z x) xs
>
> The lgo recursive call is then specialised at the call site and we can
> get good code.
>
> As I understand it, if foldl was written in the standard directly way
> then ghc would not inline it. So we have to manually apply the static
> argument transformation. You'll see that foldr is written in the same
> way.

Similar for length et al. These worker/wrapper things inline quite
happily:

    module B where

    mylength :: [a] -> Int
    mylength = go 0
        where
            go :: Int -> [a] -> Int
            go n []     = n
            go n (_:xs) = go (n+1) xs
    {-# INLINE mylength #-}

    module A where

    import B

    main = print (mylength (enumFromTo 1 (10::Int)))

------------------------------------------------------------------------

And it is all inlined into A.hs:

    A.lvl2 =
      case A.go1 @ Int A.lvl A.lvl1 of w_axy { I# ww_axA ->
      $wshowSignedInt 0 ww_axA ([] @ Char)
      }

    A.go1 :: forall a1_a5n. Int -> [a1_a5n] -> Int
    A.go1 =
      \ (@ a1_a7b) (n_a5p :: Int) (ds_d9N :: [a1_a7b]) ->
        case ds_d9N of wild_B1 {
          [] -> n_a5p;
          : ds1_d9O xs_a5s ->
            A.go1
              @ a1_a7b
              (case n_a5p of wild1_aqC { I# x_aqE ->
               I# (+# x_aqE 1)
               })
              xs_a5s


-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Announce: ghc-core, command line pager for reading GHC Core

Henning Thielemann
In reply to this post by Henning Thielemann

On Fri, 23 May 2008, Ketil Malde wrote:

> Henning Thielemann <[hidden email]> writes:
>
>>> An even more advanced tool could show differences between two Core
>>> listings [..]
>> In this special example, actually simple 'diff' spotted the critical
>> difference
>
> I would suggest Emacs's ediff for this, it lets you refine differing
> chunks and highlights the actual differences.  If you are an Emacs
> user, if not, there are probably other nice diff tools out there.. :-)

tkdiff, kompare
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: Announce: ghc-core, command line pager for reading GHC Core

Josef Svenningsson
In reply to this post by Duncan Coutts
On Fri, May 23, 2008 at 9:55 PM, Duncan Coutts
<[hidden email]> wrote:

>
> On Fri, 2008-05-23 at 21:24 +0200, Henning Thielemann wrote:
>> On Fri, 23 May 2008, Bulat Ziganshin wrote:
>>
>> > Hello Henning,
>> >
>> > Friday, May 23, 2008, 8:31:24 PM, you wrote:
>> >
>> >> would guarantee speed in every case. Or I can SPECIALISE the function,
>> >> then the function will only be called, but with polymorphism overhead
>> >> eliminated. This would only work for a restricted range of types. I'd like
>> >> to have a pragma, that tells GHC to specialise a function for every type
>> >> it is called with.
>> >
>> > me too. btw, this already present in jhc. inlining doesn't work in any
>> > complex case since recursive functions can't be inlined
>>
>> GHC inlines recursive functions, too, otherwise it could not turn 'foldl'
>> and friends into plain machine loops.
>
> Actually ghc's definition of foldl is not recursive, though it does of
> course contain a local recursion:
>
> foldl        :: (a -> b -> a) -> a -> [b] -> a
> foldl f z xs = lgo z xs
>             where
>                lgo z []     =  z
>                lgo z (x:xs) = lgo (f z x) xs
>
> The lgo recursive call is then specialised at the call site and we can
> get good code.
>
> As I understand it, if foldl was written in the standard directly way
> then ghc would not inline it. So we have to manually apply the static
> argument transformation. You'll see that foldr is written in the same
> way.
>
Note that the static argument transformation (SAT) was recently
revived in ghc. Info from the patch:
Fri Apr 11 18:21:37 CEST 2008  [hidden email]
  * Revive the static argument transformation

  This patch revives the Static Argument Transformation, thanks to
  Max Bolingbroke.  It is enabled with
        -fstatic-argument-transformation
  or    -O2

  Headline nofib results

                    Size    Allocs   Runtime
  Min             +0.0%    -13.7%    -21.4%
  Max             +0.1%     +0.0%     +5.4%
  Geometric Mean  +0.0%     -0.2%     -6.9%

Haskell programs just keep getting faster and faster. And having ghc
do the SAT to enable inlining recursive functions is really nice.

Cheers,

Josef
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe