<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Yes, see
<a class="moz-txt-link-freetext" href="https://gitlab.haskell.org/ghc/ghc/-/wikis/Plan-for-increased-parallelism-and-more-detailed-intermediate-output">https://gitlab.haskell.org/ghc/ghc/-/wikis/Plan-for-increased-parallelism-and-more-detailed-intermediate-output</a>
where we (Obsidian) and IOHK have been planning together.<br>
</p>
<p>I must saw, I am a bit skeptical about a GSOC being able to take
this on successfully. I thought Fendor did a great job with
multiple home units, for example, but we have still to finish
merging all his work! The driver is perhaps the biggest cesspool
of technical debt in GHC, and it will take a while to untangle let
alone implement new features.</p>
<p>I forget what the rules are for more incremental or multifaceted
projects, but I would prefer an approach of trying to untangle
things with no singular large goal. Or maybe we can involve a
student with efforts to improve CI, attacking the root cause for
why it's so hard to land things in the first place .<br>
</p>
<p>John<br>
</p>
<div class="moz-cite-prefix">On 3/12/21 7:11 PM, Moritz Angermann
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKfdd-z97HOgHEMWurxumK9HjP=tUPioxJtZsvW=+8ejjcb2uQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">Yes there is also John resumable compilation
ideas. And the current performance work obsidian systems does. </div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, 13 Mar 2021 at 6:21
AM, Cheng Shao <<a href="mailto:cheng.shao@tweag.io"
moz-do-not-send="true">cheng.shao@tweag.io</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">I believe
Josh has already been working on 2 some time ago? cc'ing him<br>
to this thread.<br>
<br>
I'm personally in favor of 2 since it's also super useful
for<br>
prototyping whole-program ghc backends, where one can just
read all<br>
the CgGuts from the .hi files, and get all codegen-related
Core for<br>
free.<br>
<br>
Cheers,<br>
Cheng<br>
<br>
On Fri, Mar 12, 2021 at 10:32 PM Zubin Duggal <<a
href="mailto:zubin.duggal@gmail.com" target="_blank"
moz-do-not-send="true">zubin.duggal@gmail.com</a>>
wrote:<br>
><br>
> Hi all,<br>
><br>
> This is following up on this recent discussion on the
list concerning fat<br>
> interface files: <a
href="https://mail.haskell.org/pipermail/ghc-devs/2020-October/019324.html"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mail.haskell.org/pipermail/ghc-devs/2020-October/019324.html</a><br>
><br>
> Now that we have been accepted as a GSOC organisation,
I think<br>
> it would be a good project idea for a sufficiently
motivated and<br>
> advanced student. This is a call for mentors (and
students as<br>
> well!) who would be interested in this project<br>
><br>
> The problem is the following:<br>
><br>
> Haskell Language Server (and ghci with `-fno-code`)
have very<br>
> fast startup times for codebases which don't make use
of Template<br>
> Haskell, and thus don't require any code-gen to
typecheck. This<br>
> is because they can simply read the cached iface files
generated by a<br>
> previous compile and don't need to re-invoke the
typechecker.<br>
><br>
> However, as soon as TH is involved, we are forced to
retypecheck and<br>
> compile files, since it is not possible to restart the
code-gen process<br>
> starting with only a iface file. I can think of two
ways to address this<br>
> problem:<br>
><br>
> 1. Allow bytecode to be serialized<br>
><br>
> 2. Serialize desugared Core into iface files (fat
interfaces), so that<br>
> (byte)code-gen can be restarted from this point and
doesn't need<br>
><br>
> (1) might be challenging, but offers a few more
advantages over (2),<br>
> in that we can reduce the work done to load TH-heavy
codebases to just<br>
> a load of the cached bytecode objects from disk, and
could make the<br>
> load process (and times) for these codebases directly
comparable to<br>
> their TH-free cousins.<br>
><br>
> It would also make ghci startup a lot faster with a
warm cache of<br>
> bytecode objects, bringing ghci startup times in line
with those of<br>
> -fno-code<br>
><br>
> However (2) might be much easier to achieve and offers
many<br>
> of the same advantages, in that we would not need to
re-run<br>
> the compiler frontend or core-to-core optimisation
phases.<br>
> There is also already a (slightly bitrotted)
implementation<br>
> of (2) thanks to the work of Edward Yang.<br>
><br>
> If any of this sounds exciting to you as a student or a
mentor, please<br>
> get in touch.<br>
><br>
> In particular, I think (2) is a feasible project that
can be completed<br>
> with minimal mentoring effort. However, I'm only
vaguely familiar with<br>
> the details of the byte code generator, so if (1) is a
direction we want<br>
> to pursue, we would need a mentor familiar with the
details of this part<br>
> of GHC.<br>
><br>
> Cheers,<br>
> Zubin<br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org" target="_blank"
moz-do-not-send="true">ghc-devs@haskell.org</a><br>
> <a
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank"
moz-do-not-send="true">ghc-devs@haskell.org</a><br>
<a
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>