GHC development asks too much of the host system

[Artem Pelenitsyn]

Thanks Ben, very interesting, especially the cloud Shake stuff.

> If everyone were to use, e.g.,
>   ghc.nix this could be largely mitigated, but this isn't the world in
>   which we live.

I don't know why you'd want everyone to use it necessarily to improve
things.
If there was a clear statement that you may elect to use ghc.nix and get X%
speedup,
that would be a good start. And then people can decide, based on their setup
and their aversion to tools like Nix, etc. in general.

The real issue is that currently you don't benefit much from ghc.nix
because the main
performance sink is the GHC tree itself. The way out is to use a cloud
build system, most likely
Cloud Shake, which, as you describe, has a couple of issues in this case:

1) Native dependencies. This should be possible to solve via Nix, but
unfortunately,
this is not quite there yet because Shake doesn't know about Nix (afaik). I
think to actually get
there, you'd need some sort of integration between Nix and Shake akin to
what Tweag
built for Nix and Bazel (cf. rules_nixpkgs [1]). Their moto is: Nix for
"external" or "system"
components, and Bazel for "internal" or "local" ones.

2) Bootstrapping aspect. Maybe this is a challenge for rebuilds after
modification,
but I think people on this thread were quoting the "time to first build"
more.
I don't see how avoiding to build master locally after a fresh (worktree)
checkout by
downloading build results from somewhere, connects to bootstrapping. I
think it doesn't.

As for rebuilds. People are already using --freeze1 (you suggested it
earlier in this very thread!),
so I don't see how saying "freezing stage 1 is dangerous even if faster"
connects to practise of
GHC development. Of course, you may not find a remote cache with relevant
artefacts after
local updates, but that's not the point. The point is to not have to build
`master`, not
`feaure-branch-t12345`. Rebuilds should be rather pain-free in comparison.

--
Best, Artem

[1]: https://github.com/tweag/rules_nixpkgs


On Tue, 19 Jul 2022 at 18:03, Ben Gamari <ben at smart-cactus.org> wrote:

> Artem Pelenitsyn <a.pelenitsyn at gmail.com> writes:
>
> > Hey everyone! I'm not a frequent contributor but I observed similar
> > challenges as Hécate. I notice couple points.
> >
> > ### HLS and other editor integrations
> >
> > I've never tried HLS for GHC development but it absolutely chokes on
> > Cabal for me (a $2K laptop), so I'm not surprised it's having troubles
> > with GHC. I've never tried to dig into it, but I heard before that
> > disabling plugins is a good start.
> >
> > Ghcid (after the introduction of ghc-in-ghci) was interesting but still
> on
> > a slow side.
> >
> > I once tried to generate ETAGS and use them from Emacs (with plain
> > haskell-mode): this was quite nice. As Moritz, I didn't use much above
> > syntax coloring, but ETAGS allowed jumping to definitions, which is
> > important. Maintaining tags wasn't fun, on the other hand.
> >
> > In all fairness, I think that's an issue with HLS more than with GHC.
> >
> > ### Build Times
> >
> > I have been using a dedicated server for this, but this still was
> > painful at times (even git clone takes non-negligible amount of time,
> > and I never got used to git worktree because of a hoop you have to
> > jump over, which I already forgot but I know it can be looked up in
> > Andreas Herrmann's presentation on developing GHC). I'm surprised no
> > one seems to try to challenge the status quo.
> >
> IMHO, `git worktree` is indispensible. Not only does it make cloning
> cheaper but it makes it trivial to share commits between work trees,
> which is incredibly helpful when cleaning up branch history,
> backporting, and other common tasks. I just wish it also worked
> transparently for submodules.
>
> > Hadrian is a Shake application. How is Cloud Shake doing? In the era
> > of Nix and Bazel you start assuming niceties like remote caching. It'd
> > be great to improve on this front as it just feels very wrong
> > rebuilding master again and again on every contributor's computer.
> > Especially after so much effort put into GHC modularity, which, I
> > believe, should make it easier to cache.
>
> Sadly using Cloud Shake in Hadrian ran into some rather fundamental
> difficulties:
>
>  * GHC has native dependencies (namely, the native toolchain, ncurses,
>    gmp, and possible libdw and libnuma). If everyone were to use, e.g.,
>    ghc.nix this could be largely mitigated, but this isn't the world in
>    which we live.
>
>  * GHC is a bootstrapped compiler. Consequently, most changes will
>    invalidate well over half of the build cache (that is, everything
>    built by stage 1). This significantly limits the benefit that one
>    could gain from Cloud Shake, especially since in the typical
>    development workflow the stage 1 build (which is where most of the
>    caching benefit would be seen) is a rather small cost (IIRC it takes
>    around 5 minutes to make it to the stage 2 build on my machine).
>
>    One might think that we could simply "freeze" the stage 1 compiler,
>    but in general this is not safe. For instance, it would break subtly
>    on any change to known keys, the interface file format, the ABI, or
>    primop definitions.
>
> >
> > It's sad that GHC still needs ./boot && ./configure: this can preclude
> any
> > remote caching technology that I can imagine. At one point it seemed like
> > configure could go into Hadrian, but it didn't really happen.
> >
> I don't see us moving away from `configure` (or something like it) as
> long as GHC has native dependencies. Having a clear separation between
> "configuration" and "building" is very much necessary to maintain sanity.
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220719/a3dbb38a/attachment.html>