Re: Where do I start if I would like help improve GHC compilation times?

Pretty-printing the asm is a likely contender for optimisation, however the problem is not the pretty-printing per se. We don't actually use any of the backtracking stuff when printing asm, since there's no point nicely indenting things or wrapping lines. The overhead is probably all in the layer of data structure that we generate in Pretty before it gets dumped into raw bytes. Using a ByteString Builder instead might yield some improvement. Cheers Simon On 17 April 2017 at 18:44, Alfredo Di Napoli wrote:

Dear all,

after sprinkling (ehm, littering) GHC source code with cost centres, I was not surprised to see that roughly 20% of the compilation time (as in .prof) was spent in the core gen/simplification process (10% of the total time) and on the asm code gen (another 10%).

I have almost immediately abandoned the idea of try optimising some modules in simplCore (considering my 0-knowledge of GHC internals anyway..) but I have been dwelling on the following: Outputable.hs and Pretty.hs seems to be have been implemented making deliberate use of lists and concatenations between them, which left me wondering if there was room for optimisation there. I have found this interesting paper on the topic:

https://www.cs.kent.ac.uk/pubs/2005/2062/content.pdf

Now, it’s totally possible that this has been already tried (with no success) but judging from the original copyright of Pretty.hs (dated 2001), it seems it was written prior to the work of Olaf Chitil (the author of the paper).

TL;DR I was thinking (even just as a fun exercise to learn more about GHC internals) to leverage the ideas of that paper and switch to a different implementation for `Doc` coupled with the use of lazy dequeues, which *might* increase the performances of the codegen and thus of the compiler overall. Am I fighting a strawman (or flogging a dead horse, pick your rethorical figure :D ) or is there even a tiny chance of this being actually useful?

Have a nice evening,

Alfredo

On 11 April 2017 at 00:47, Ben Gamari wrote:

...

Alfredo Di Napoli writes:

...

Hey Ben,

Hi Alfredo,

Sorry for the late response! The email queue from the weekend was a bit longer than I would like.

...

as promised I’m back to you with something more articulated and hopefully meaningful. I do hear you perfectly — probably trying to dive head-first into this without at least a rough understanding of the performance hotspots or the GHC overall architecture is going to do me more harm than good (I get the overall picture and I’m aware of the different stages of the GHC compilation pipeline, but it’s far from saying I’m proficient with the architecture as whole). I have also read a couple of years ago the GHC chapter on the “Architeture of Open Source Applications” book, but I don’t know how much that is still relevant. If it is, I guess I should refresh my memory.

It sounds like you have done a good amount of reading. That's great. Perhaps skimming the AOSA chapter again wouldn't hurt, but otherwise it's likely worthwhile diving in.

...

I’m currently trying to move on 2 fronts — please advice if I’m a fool flogging a dead horse or if I have any hope of getting anything done ;)

1. I’m trying to treat indeed the compiler as a black block (as you adviced) trying to build a sufficiently large program where GHC is not “as fast as I would like” (I know that’s a very lame definition of “slow”, hehe). In particular, I have built the stage2 compiler with the “prof” flavour as you suggested, and I have chosen 2 examples as a reference “benchmark” for performance; DynFlags.hs (which seems to have been mentioned multiple times as a GHC perf killer) and the highlighting-kate package as posted here: https://ghc.haskell.org/trac/ghc/ticket/9221 .

Indeed, #9221 would be a very interesting ticket to look at. The highlighting-kate package is interesting in the context of that ticket as it has a very large amount of parallelism available.

If you do want to look at #9221, note that the cost centre profiler may not provide the whole story. In particular, it has been speculated that the scaling issues may be due to either,

* threads hitting a blackhole, resulting in blocking

* the usual scaling limitations of GHC's stop-the-world GC

The eventlog may be quite useful for characterising these.

...

The idea would be to compile those with -v +RTS -p -hc -RTS enabled, look at the output from the .prof file AND the `-v` flag, find any hotspot, try to change something, recompile, observe diff, rinse and repeat. Do you think I have any hope of making progress this way? In particular, I think compiling DynFlags.hs is a bit of a dead-end; I whipped up this buggy script which escalated into a Behemoth which is compiling pretty much half of the compiler once again :D

``` #!/usr/bin/env bash

../ghc/inplace/bin/ghc-stage2 --make -j8 -v +RTS -A256M -qb0 -p -h \ -RTS -DSTAGE=2 -I../ghc/includes -I../ghc/compiler -I../ghc/compiler/stage2 \ -I../ghc/compiler/stage2/build \ -i../ghc/compiler/utils:../ghc/compiler/types:../ghc/compile r/typecheck:../ghc/compiler/basicTypes \ -i../ghc/compiler/main:../ghc/compiler/profiling:../ghc/comp iler/coreSyn:../ghc/compiler/iface:../ghc/compiler/prelude \ -i../ghc/compiler/stage2/build:../ghc/compiler/simplStg:../ ghc/compiler/cmm:../ghc/compiler/parser:../ghc/compiler/hsSyn \ -i../ghc/compiler/ghci:../ghc/compiler/deSugar:../ghc/compil er/simplCore:../ghc/compile/specialise \ -fforce-recomp -c $@ ```

I’m running it with `./dynflags.sh ../ghc/compiler/main/DynFlags.hs` but it’s taking a lot to compile (20+ mins on my 2014 mac Pro) because it’s pulling in half of the compiler anyway :D I tried to reuse the .hi files from my stage2 compilation but I failed (GHC was complaining about interface file mismatch). Short story short, I don’t think it will be a very agile way to proceed. Am I right? Do you have any recommendation in such sense? Do I have any hope to compile DynFlags.hs in a way which would make this perf investigation feasible?

What I usually do in this case is just take the relevant `ghc` command line directly from the `make` output and execute it manually. I would imagine your debug cycle would look something like,

* instrument the compiler * build stage1 * use stage2 to build DynFlags using the stage1 compiler (using a saved command line) * think * repeat

This should only take a few minutes per iteration.

...

The second example (the highlighting-kate package) seems much more promising. It takes maybe 1-2 mins on my machine, which is enough to take a look at the perf output. Do you think I should follow this second lead? In principle any 50+ modules package I think would do (better if with a lot of TH ;) ) but this seems like a low-entry barrier start.

2. The second path I’m exploring is simply to take a less holistic approach and try to dive in into a performance ticket like the ones listed here: https://www.reddit.com/r/haskell/comments/45q90s/is_anything _being_done_to_remedy_the_soul/czzq6an/ Maybe some are very specific, but it seems like fixing small things and move forward could help giving me understanding of different sub-parts of GHC, which seems less intimidating than the black-box approach.

Do you have any specific tickets from these lists that you found interesting?

...

In conclusion, what do you think is the best approach, 1 or 2, both or none? ;)

I would say that it largely depends upon what you feel most comfortable with. If you feel up for it, I think #9221 would be a nice, fairly self-contained, yet high-impact ticket which would be worth spending a few days diving further into.

Cheers,

- Ben

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs