GHC development asks too much of the host system

Tue Jul 19 18:00:24 UTC 2022

(re-sending with replay-all this time)

Hi Simon, thank you for your concern.

Regarding the compiler compilation:
I often have to re-run ./configure and ./boot between development phases 
(usually spaced by one or two weeks), which prevents me from benefiting 
from `--freeze1` from the get-go.
The flavour I use is `Quick`, as it is advertised on https://ghc.dev.
The technique I use now is to restrict the `-j` parameter to 1 or 2. I 
can go above for night builds, but if I want to keep my system usable, 
this is how it goes.
This takes 47m07s according to Hadrian.

Moreover, modern computers have a BIOS setting that shuts down the 
computer when the temperature is too high (between 70°C and 100°C I 
believe). I ended up upping this limit in my BIOS some time ago, but I 
wish I didn't need to.
(and yes I do frequently remove the dust ;)

Regarding documentation contribution,
The time it takes to run `hadrian/build -j --flavour=Quick` *plus* 
`hadrian/build -j2 --freeze1 --flavour=Quick docs --docs=no-sphinx-pdfs 
` in order to render the haddocks is way too high for occasional 
contributors.

I started a process while writing this email, in order to get fresh and 
accurate numbers, and here is what I got in return:

juil. 19 19:37:21 elatha systemd[1759]: 
app-kitty-dedaa3d5a1ee43dd8b2552b7afd53cd5.scope: systemd-oomd killed 36 
process(es) in this unit.
juil. 19 19:37:21 elatha systemd-oomd[682429]: Killed 
/user.slice/user-1000.slice/user at 1000.service/app.slice/app-kitty-dedaa3d5a1ee43dd8b2552b7afd53cd5.scope 
due to memory used (16192806912) / total (16358338560) and swap used 
(8102125568) / total (8589930496) being more than 90.00%

Now regarding HLS, I remember that a point of marketing for it is that 
it supports GHC. Considering the very skilled people who hold the wheel 
of HLS development, my first (nor second) reflex isn't to doubt them. So 
yes I believe I must disable HLS when working on GHC, but then how do we 
spread this kind of information / work-around while at the same time 
saying "but HLS is still reliable, pinky swear, it's just that it 
doesn't scale".

I do not doubt that HLS does some heavy stuff and I'm truly grateful for 
all the times where it detects unused imports, unused extensions, and 
even inserts import lines for me! But I find it hard to promote HLS 
whilst also putting an asterisk that says "Provided that you can afford 
it".

This is pretty much all I can observe. I'd be more than happy to have 
better observability into the build process, though!
I'm not too desperate for the future, because chatting with Bryan gave 
me hope for progress in that area.
Le 19/07/2022 à 18:29, Simon Peyton Jones a écrit :
> That's bad Hecate. We need GHC to be fun to work with, not a pain.
>
> Can you be (much) more specific?  The more concrete the problem, the 
> more likely we can address it.
>
> e.g. What if you don't use HLS?  Or maybe Hadrian is building much 
> more than you need? It would be super helpful to have more 
> information.  There may be things we can't reasonably address (e.g. 
> make a small, light, non-optimising compiler instead, throwing away 
> most of the code base) but I bet that sheer size isn't the only factor.
>
> Thanks!
>
> Simon
>
> On Tue, 19 Jul 2022 at 17:21, Hécate <hecate at glitchbra.in> wrote:
>
>     Hello ghc-devs,
>
>     I hadn't made significant contributions to the GHC code base in a
>     while,
>     until a few days ago, where I discovered that my computer wasn't
>     able to
>     sustain running the test suite, nor handle HLS well.
>
>     Whether it is my OS automatically killing the process due to
>     oom-killer
>     or just the fact that I don't have a war machine, I find it too
>     bad and
>     I'm frankly discouraged.
>     This is not the first time such feedback emerges, as the
>     documentation
>     task force for the base library was unable to properly onboard some
>     people from third-world countries who do not have access to hardware
>     we'd consider "standard" in western Europe or some parts of North
>     America. Or at least "standard" until even my standard stuff
>     didn't cut
>     it anymore.
>
>     So yeah, I'll stay around but I'm afraid I'm going to have to
>     focus on
>     projects for which the feedback loop is not on the scale of hours
>     , as
>     this is a hobby project.
>
>     Hope this will open some eyes.
>
>     Cheers,
>     Hécate
>
>     -- 
>     Hécate ✨
>     🐦: @TechnoEmpress
>     IRC: Hecate
>     WWW: https://glitchbra.in
>     RUN: BSD
>
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW:https://glitchbra.in
RUN: BSD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220719/4f8c8c2c/attachment.html>