<div dir="ltr">Hey Ben,<div><br></div><div>thanks for the quite exhaustive reply! I’m on the go right now, but I promise to get back to you with a meaningful reply later this weekend ;)</div><div><br></div><div>Alfredo</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 7 April 2017 at 18:22, Ben Gamari <span dir="ltr"><<a href="mailto:ben@smart-cactus.org" target="_blank">ben@smart-cactus.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Alfredo Di Napoli <<a href="mailto:alfredo.dinapoli@gmail.com">alfredo.dinapoli@gmail.com</a>> writes:<br>
<br>
> Hey folks,<br>
><br>
Hi Alfredo!<br>
<br>
First, thanks for writing. More eyes looking at GHC's compiler<br>
performance is badly needed.<br>
<span class=""><br>
> maybe I’m setting up for something too ambitious for me, but I would like<br>
> to take an active stance to the overlasting “GHC compilation times are<br>
> terrible” matter, instead of simply stare at the screen with despair<br>
> whenever GHC compiles a sufficiently large Haskell program ;)<br>
><br>
> To make this even more interesting, I have never contributed to GHC either!<br>
> The max I have pushed myself into was 2 years ago when I successfully built<br>
> GHC head from source and tried to fix an Haddock “easy” ticket I don’t even<br>
> recall (full disclosure, eventually I didn’t :D ).<br>
><br>
> Specifically, I would love community recommendations & guidance about:<br>
><br>
> 1. Is this simply too daunting for somebody like me? Maybe is better to<br>
> first start contributing more regularly, take confidence with the code base<br>
> AND then move forward?<br>
><br>
</span>As with any software project, it is possible to treat the compiler as a<br>
black box, throw a profiler at it and see what hotspots show up. This<br>
gives you a place to focus your effort, allowing you to learn a small<br>
area and broaden your knowledge as necessary.<br>
<br>
However, I think it's fair to say that you will be significantly more<br>
productive if you first develop a basic understanding of the compilation<br>
pipeline. I'd recommend having a look at the GHC Commentary [1] for a<br>
start.<br>
<br>
I think it also helps to have a rough idea of what "slow" means to you.<br>
I find it is quite helpful if you have a particular program which you<br>
feel compiles more slowly than you would like (especially if it even<br>
compiles slowly with -O0, since then much less of the compiler is<br>
involved in compilation). Another approach is to look for programs whose<br>
compilation time has regressed over the course of GHC releases. It is<br>
not hard to find these examples and it is often possible to bisect your<br>
way back to the regressing commit.<br>
<br>
Also, note that I have collected some notes pertaining to compiler<br>
performance on the Wiki [2]. Here you will find a number of tickets of<br>
interest (as well a some rough themes which I've noticed), some nofib<br>
results which might guide your efforts, as well as a list of some<br>
fixes which have been committed in the past.<br>
<br>
[1] <a href="https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/<wbr>ghc/wiki/Commentary/Compiler</a><br>
[2] <a href="https://ghc.haskell.org/trac/ghc/wiki/Performance/Compiler" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/<wbr>ghc/wiki/Performance/Compiler</a><br>
<span class=""><br>
> 2. Are compilation times largely dependant from the target platform (I’m on<br>
> Darwin) or there is something which can be done “globally” so that the<br>
> benefits can be experienced by everybody?<br>
><br>
</span>There are some external considerations (e.g. the platform's compiler and<br>
linking toolchain) which contribute to GHC's runtime. For instance, it<br>
is known that the BFD ld linker implementation that many Linux<br>
distributions use by default is a great deal slower than it could be.<br>
This particular issue has come up recently and I'm currently working on<br>
allowing us to use the more performant gold linker when available.<br>
<br>
However, I think it's fair to say that for most programs GHC's runtime<br>
is largely independent of platform. I would invite you to try compiling<br>
a package which you consider GHC to compile "slowly" with GHC's -v flag<br>
(and GHC 8.0.1 or newer). This will give you a rough breakdown of where<br>
time is spent. For many packages you will find that the simplifier<br>
and/or typechecker dominate, followed (often distantly) by native code<br>
generation. Of these steps native code generation is the only one with a<br>
strong platform dependence.<br>
<span class=""><br>
> 3. Is there any recommended workflow to profile GHC compilation times? Is<br>
> there any build flavour one should prefer when doing so? (Maybe the full,<br>
> slowest one?)<br>
><br>
</span>There are a few options here:<br>
<br>
 * As of GHC 8.0 the compiler will output timing and allocation<br>
   information for its various stages if run with -v. This can be<br>
   extremely helpful to get a high-level picture of where the compiler<br>
   is spending its time while compiling your program. This is almost<br>
   always the right place to start.<br>
<br>
 * As with any Haskell program, the cost centre profiler can be used to<br>
   characterize the memory and CPU behavior of various parts of the<br>
   compiler.<br>
<br>
   GHC's source tree includes a "prof" build flavour which builds the<br>
   compiler with profiling enabled. However it only includes a handful<br>
   of cost-centres and is best used when you already have a rough idea<br>
   where you are looking and can add further cost-centres to drill down<br>
   to your hotspot.<br>
<br>
   Simply enabling -fprof-exported across the entire tree just doesn't<br>
   work in my experience: not only is the resulting compiler quite slow,<br>
   but the profile you get is far too unwieldy to learn from.<br>
<br>
 * Occassionally the ticky-ticky profiler can be helpful in identifying<br>
   allocation hotspots without the full overhead of the cost-centre<br>
   profiler.<br>
<br>
 * In principle our newly-stable DWARF debug information can be used for<br>
   profiling, although this is still a work in progress and requires a<br>
   patched GHC for best results. It's probably best to stick to the more<br>
   traditional profiling mechanisms for now.<br>
<br>
Anyways, I hope this helps. Always feel free to get in touch with me<br>
personally (IRC and email are both great) if you would like to discuss<br>
particular issues. Thanks again for your interest!<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
</blockquote></div><br></div>