<div dir="ltr"><div>Thanks Ben, very interesting, especially the cloud Shake stuff.</div><div><br></div><div>> If everyone were to use, e.g.,<br>> ghc.nix this could be largely mitigated, but this isn't the world in<br>
> which we live.</div><div><br></div><div>I don't know why you'd want everyone to use it necessarily to improve things. <br></div><div>If there was a clear statement that you may elect to use ghc.nix and get X% speedup, <br></div><div>that would be a good start. And then people can decide, based on their setup</div><div>and their aversion to tools like Nix, etc. in general.<br></div><div><br></div><div>The real issue is that currently you don't benefit much from ghc.nix because the main <br></div><div>performance sink is the GHC tree itself. The way out is to use a cloud build system, most likely</div><div>Cloud Shake, which, as you describe, has a couple of issues in this case:</div><div><br></div><div>1) Native dependencies. This should be possible to solve via Nix, but unfortunately, <br></div><div>this is not quite there yet because Shake doesn't know about Nix (afaik). I think to actually get</div><div>there, you'd need some sort of integration between Nix and Shake akin to what Tweag</div><div>built for Nix and Bazel (cf. rules_nixpkgs [1]). Their moto is: Nix for "external" or "system"</div><div>components, and Bazel for "internal" or "local" ones.<br></div><div><br></div><div>2) Bootstrapping aspect. Maybe this is a challenge for rebuilds after modification, <br></div><div>but I think people on this thread were quoting the "time to first build" more.</div><div>I don't see how avoiding to build master locally after a fresh (worktree) checkout by</div><div>downloading build results from somewhere, connects to bootstrapping. I think it doesn't.</div><div><br></div><div>As for rebuilds. People are already using --freeze1 (you suggested it earlier in this very thread!), <br></div><div>so I don't see how saying "freezing stage 1 is dangerous even if faster" connects to practise of <br></div><div>GHC development. Of course, you may not find a remote cache with relevant artefacts after</div><div>local updates, but that's not the point. The point is to not have to build `master`, not</div><div>`feaure-branch-t12345`. Rebuilds should be rather pain-free in comparison.<br></div><div><br></div><div>--</div><div>Best, Artem</div><div><br></div><div>[1]: <a href="https://github.com/tweag/rules_nixpkgs">https://github.com/tweag/rules_nixpkgs</a></div><div><br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Jul 2022 at 18:03, 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">Artem Pelenitsyn <<a href="mailto:a.pelenitsyn@gmail.com" target="_blank">a.pelenitsyn@gmail.com</a>> writes:<br>
<br>
> Hey everyone! I'm not a frequent contributor but I observed similar<br>
> challenges as Hécate. I notice couple points.<br>
><br>
> ### HLS and other editor integrations<br>
><br>
> I've never tried HLS for GHC development but it absolutely chokes on<br>
> Cabal for me (a $2K laptop), so I'm not surprised it's having troubles<br>
> with GHC. I've never tried to dig into it, but I heard before that<br>
> disabling plugins is a good start.<br>
><br>
> Ghcid (after the introduction of ghc-in-ghci) was interesting but still on<br>
> a slow side.<br>
><br>
> I once tried to generate ETAGS and use them from Emacs (with plain<br>
> haskell-mode): this was quite nice. As Moritz, I didn't use much above<br>
> syntax coloring, but ETAGS allowed jumping to definitions, which is<br>
> important. Maintaining tags wasn't fun, on the other hand.<br>
><br>
> In all fairness, I think that's an issue with HLS more than with GHC.<br>
><br>
> ### Build Times<br>
><br>
> I have been using a dedicated server for this, but this still was<br>
> painful at times (even git clone takes non-negligible amount of time,<br>
> and I never got used to git worktree because of a hoop you have to<br>
> jump over, which I already forgot but I know it can be looked up in<br>
> Andreas Herrmann's presentation on developing GHC). I'm surprised no<br>
> one seems to try to challenge the status quo.<br>
><br>
IMHO, `git worktree` is indispensible. Not only does it make cloning<br>
cheaper but it makes it trivial to share commits between work trees,<br>
which is incredibly helpful when cleaning up branch history,<br>
backporting, and other common tasks. I just wish it also worked<br>
transparently for submodules.<br>
<br>
> Hadrian is a Shake application. How is Cloud Shake doing? In the era<br>
> of Nix and Bazel you start assuming niceties like remote caching. It'd<br>
> be great to improve on this front as it just feels very wrong<br>
> rebuilding master again and again on every contributor's computer.<br>
> Especially after so much effort put into GHC modularity, which, I<br>
> believe, should make it easier to cache.<br>
<br>
Sadly using Cloud Shake in Hadrian ran into some rather fundamental<br>
difficulties:<br>
<br>
* GHC has native dependencies (namely, the native toolchain, ncurses,<br>
gmp, and possible libdw and libnuma). If everyone were to use, e.g.,<br>
ghc.nix this could be largely mitigated, but this isn't the world in<br>
which we live.<br>
<br>
* GHC is a bootstrapped compiler. Consequently, most changes will<br>
invalidate well over half of the build cache (that is, everything<br>
built by stage 1). This significantly limits the benefit that one<br>
could gain from Cloud Shake, especially since in the typical<br>
development workflow the stage 1 build (which is where most of the<br>
caching benefit would be seen) is a rather small cost (IIRC it takes<br>
around 5 minutes to make it to the stage 2 build on my machine).<br>
<br>
One might think that we could simply "freeze" the stage 1 compiler,<br>
but in general this is not safe. For instance, it would break subtly<br>
on any change to known keys, the interface file format, the ABI, or<br>
primop definitions.<br>
<br>
><br>
> It's sad that GHC still needs ./boot && ./configure: this can preclude any<br>
> remote caching technology that I can imagine. At one point it seemed like<br>
> configure could go into Hadrian, but it didn't really happen.<br>
><br>
I don't see us moving away from `configure` (or something like it) as<br>
long as GHC has native dependencies. Having a clear separation between<br>
"configuration" and "building" is very much necessary to maintain sanity.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
</blockquote></div></div>