Measuring performance of GHC

[Ben Gamari]

Johannes Waldmann <johannes.waldmann at htwk-leipzig.de> writes:

> Hi,
>
>> ... to compile it with a profiled GHC and look at the report?
>
> How hard is it to build hackage or stackage
> with a profiled ghc? (Does it require ghc magic, or can I do it?)
>
Not terribly hard although it could be made smoother.

To start you'll need to compile a profiled GHC. To do this you simply
want to something like the following,

 1. install the necessary build dependencies [1]
 2. get the sources [2]
 3. configure the tree to produce a profiled compiler:
   a. cp mk/build.mk.sample mk/build.mk
   b. uncomment the line `BuildFlavour=prof` in mk/build.mk
 4. `./boot && ./configure --prefix=$dest && make && make install`

Then for a particular package,

 1. get a working directory: `cabal unpack $pkg && cd $pkg-*`
 2. `args="--with-ghc=$dest/bin/ghc --allow-newer=base,ghc-prim,template-haskell,..."`
 3. install dependencies: `cabal install --only-dependencies $args .`
 4. run the build, `cabal configure --ghc-options="-p -hc" $args && cabal build`

You should end up with a .prof and .hp file. Honestly, I often skip the
`cabal` step entirely and just use `ghc` to compile a module of interest
directly.


[1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation
[2] https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources


>> ... some obvious sub-optimal algorithms in GHC.
>
> obvious to whom? you mean sub-optimality is already known,
> or that it would become obvious once the reports are there?
>
I think "obvious" may have been a bit of a strong word here. There are
sub-optimal algorithms in the compiler and they can be found with a bit
of work. If you have a good testcase tickling such an algorithm finding
the issue can be quite straightforward; if not then the process can be a
bit trickier. However, GHC is just another Haskell program and
performance issues are approached just like in any other project.


> Even without profiling - does hackage collect timing information from
> its automated builds?
>
Sadly it doesn't. But...

> What needs to be done to add timing information in places like
> https://hackage.haskell.org/package/obdd-0.6.1/reports/1 ?
>
I've discussed the possibility with Herbert to add instrumentation in
his matrix builder [3] to collect this sort of information.

As a general note, keep in mind that timings are quite unstable,
dependent upon factors beyond our control at all levels of the stack.
For this reason, I generally prefer to rely on allocations, not
runtimes, while profiling.

As always, don't hesitate to drop by #ghc if you run into trouble.

Cheers,

- Ben


[3] http://matrix.hackage.haskell.org/packages
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20161206/8116045d/attachment.sig>