<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">This is a great thread. I would love it to conclude with some concrete actions, rather than just petering out.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif">
I think one underexplored approach to addressing the build-time problem<br>
is to look not at the full-build time but rather look for common tasks<br>
where we could *avoid* doing a full build (e.g. updating documentation,<br>
typechecking `base`, running a "good enough" subset of the testsuite)<br>
and find ways to make those workflows more efficient.</div></blockquote><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">This is a great example of a concrete step. <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ul><li>Identify common tasks</li><li>Write done the procedure for doing that task<br></li></ul><div>I suspect that much waiting time is just because we are building too much. e.g. if all you want to do is typeset Haddock docs, you probably don't need the RTS build in threaded-debug way (or even at all).</div><div><br></div><div>As to the testsuite, 99% of them run fast. If there are some slow culprits that are causing genuine pain, let's identify them.<br></div></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Jul 2022 at 20:11, Ben Gamari <<a href="mailto:ben@smart-cactus.org">ben@smart-cactus.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hécate <<a href="mailto:hecate@glitchbra.in" target="_blank">hecate@glitchbra.in</a>> writes:<br>
<br>
> Hello ghc-devs,<br>
><br>
> I hadn't made significant contributions to the GHC code base in a while, <br>
> until a few days ago, where I discovered that my computer wasn't able to <br>
> sustain running the test suite, nor handle HLS well.<br>
><br>
> Whether it is my OS automatically killing the process due to oom-killer <br>
> or just the fact that I don't have a war machine, I find it too bad and <br>
> I'm frankly discouraged.<br>
<br>
Do you know which process was being killed? There is one testsuite tests<br>
that I know of which does have quite a considerable memory footprint<br>
(T16992) due to its nature; otherwise I would expect a reasonably recent<br>
machine to pass the testsuite without much trouble. It's particularly<br>
concerning if this is a new regression; is this the first time you have<br>
observed this particular failure?<br>
<br>
> This is not the first time such feedback emerges, as the documentation <br>
> task force for the base library was unable to properly onboard some <br>
> people from third-world countries who do not have access to hardware <br>
> we'd consider "standard" in western Europe or some parts of North <br>
> America. Or at least "standard" until even my standard stuff didn't cut <br>
> it anymore.<br>
><br>
> So yeah, I'll stay around but I'm afraid I'm going to have to focus on <br>
> projects for which the feedback loop is not on the scale of hours , as <br>
> this is a hobby project.<br>
><br>
> Hope this will open some eyes.<br>
><br>
Hi Hécate,<br>
<br>
I would reiterate that the more specific feedback you can offer, the<br>
better.<br>
<br>
To share my some of my own experience: I have access to a variety of hardware,<br>
some of which is quite powerful. However, I find that I end up doing<br>
much of my development on my laptop which, while certainly not a slouch<br>
(being a Ryzen 4750U), is also not a monster. In particular, while a<br>
fresh build takes nearly twice as long on my laptop than some of the<br>
other hardware I have, I nevertheless find ways to make it worthwhile<br>
(due to the ease of iteration compared to ssh). If you routinely have<br>
multi-hour iteration times then something isn't right.<br>
<br>
In particular, I think there are a few tricks which make life far<br>
easier:<br>
<br>
<br>
* Be careful about doing things that would incur<br>
significant amounts of rebuilding. This includes:<br>
<br>
* After modifying, e.g., `compiler/<a href="http://ghc.cabal.in" rel="noreferrer" target="_blank">ghc.cabal.in</a>` (e.g. to add a new<br>
module to GHC), modify `compiler/ghc.cabal` manually instead of<br>
rerunning `configure`.<br>
<br>
* Be careful about pulling/rebase. I generally pick a base commit to<br>
build off of and rebase sparingly: Having to stop what I'm doing to<br>
wait for full rebuild is an easy way to lose momentum.<br>
<br>
* Avoid switching branches; I generally have a GHC tree per on-going<br>
project.<br>
<br>
* Take advantage of Hadrian's `--freeze1` flag<br>
<br>
* Use `hadrian/ghci` to typecheck changes<br>
<br>
* Use the stage1 compiler instead of stage2 to smoke-test changes when<br>
possible. (specifically, using the script generated by Hadrian's<br>
`_build/ghc-stage1` target)<br>
<br>
* Use the right build flavour for the task at hand: If I don't need a<br>
performant compiler and am confident that I can get by without<br>
thorough testsuite validation, I use `quick`. Otherwise, plan ahead<br>
for what you need (e.g. `default+assertions+debug_info` or<br>
`validate`)<br>
<br>
* Run the fraction of the testsuite that is relevant to your change.<br>
Hadrian's `--test-way` and `--only` flags are your friends.<br>
<br>
* Take advantage of CI. At the moment we have a fair amount of CI<br>
capacity. If you think that your change is close to working, you can<br>
open an MR and start a build locally. If it fails, iterate on just the<br>
failing testcases locally.<br>
<br>
* Task-level parallelism. Admittedly, this is harder when you are<br>
working as a hobby, but I often have two or three projects on-going<br>
at a time. While one tree is building I try to make progress on<br>
another.<br>
<br>
I don't use HLS so I may be insulated from some of the pain in this<br>
regard. However, I do know that Matt is a regular user and he<br>
disables most plugins.<br>
<br>
I would also say that, sadly, GHC is comparable to other similarly-size<br>
compilers in its build time: A build of LLVM (not even clang) takes ~50<br>
minutes on my 8-core desktop; impressively, rustc takes ~7 minutes<br>
although it is a considerably smaller compiler (being just a front-end).<br>
By contrast, GHC takes around 20 minutes. I know that this doesn't<br>
make the cost any easier to bear and I would love to bring this number<br>
down, but ultimately there are only so many hours in the day.<br>
<br>
I think one underexplored approach to addressing the build-time problem<br>
is to look not at the full-build time but rather look for common tasks<br>
where we could *avoid* doing a full build (e.g. updating documentation,<br>
typechecking `base`, running a "good enough" subset of the testsuite)<br>
and find ways to make those workflows more efficient.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>