Initial compile time benchmarks

[Ben Gamari]

Ömer Sinan Ağacan <omeragacan at gmail.com> writes:

> I just benchmarked another set of packages, this time using -O2 optimized libs
> + stage 2 (6ea42c7):
>
> https://gist.githubusercontent.com/osa1/b483216953e3b02c0c79f9e4c8f8f931/raw/64001a1bfb71c0c4441c07f9f195bf5629095a6f/gistfile1.txt
>
> For me the most surprising part is that CodeGen is sometimes taking 86% of the
> time. It seems like we can start looking for improvements there. (I'll do that
> myself but I'm too busy for a few more days)
>
>
> Joachim, I think the difference is because of how thunk evaluation and cost
> centers work. If you generate a thunk with cost-center "X", you attribute the
> evaluation costs of that thunk to the cost-center "X". This is unlike how GHC
> currently printing the timing information: We essentially measure the time of
> thunk creation, not normalization of thunks. So the numbers you get from the
> profiling output may be more correct.
>
> We should try actually forcing the values in `withTiming` and see how it'll
> effect the timings. I feel like some of the costs attributed to CodeGen step
> is because of thunks we generate in previous steps. It's probably not possible
> to completely evaluate the values (because of cycles), but we can still do a
> better job probably.
>
> One last thing is that profiling can prevent some optimizations and cause
> different runtime behavior. Problems with instrumentation ...
>
Absolutely true; this is why I ultimately decided to hold off adding any
forcing in the initial patch. I had hoped to have time to do more sanity
checking of the numbers myself before the release, but sadly time hasn't
allowed. I'm very happy that you are picking up this effort. Thanks!

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160401/7d5d9c9d/attachment.sig>