Yes there is also John resumable compilation ideas. And the current performance work obsidian systems does.
On Sat, 13 Mar 2021 at 6:21 AM, Cheng Shao <cheng.s...@tweag.io> wrote: > I believe Josh has already been working on 2 some time ago? cc'ing him > to this thread. > > I'm personally in favor of 2 since it's also super useful for > prototyping whole-program ghc backends, where one can just read all > the CgGuts from the .hi files, and get all codegen-related Core for > free. > > Cheers, > Cheng > > On Fri, Mar 12, 2021 at 10:32 PM Zubin Duggal <zubin.dug...@gmail.com> > wrote: > > > > Hi all, > > > > This is following up on this recent discussion on the list concerning fat > > interface files: > https://mail.haskell.org/pipermail/ghc-devs/2020-October/019324.html > > > > Now that we have been accepted as a GSOC organisation, I think > > it would be a good project idea for a sufficiently motivated and > > advanced student. This is a call for mentors (and students as > > well!) who would be interested in this project > > > > The problem is the following: > > > > Haskell Language Server (and ghci with `-fno-code`) have very > > fast startup times for codebases which don't make use of Template > > Haskell, and thus don't require any code-gen to typecheck. This > > is because they can simply read the cached iface files generated by a > > previous compile and don't need to re-invoke the typechecker. > > > > However, as soon as TH is involved, we are forced to retypecheck and > > compile files, since it is not possible to restart the code-gen process > > starting with only a iface file. I can think of two ways to address this > > problem: > > > > 1. Allow bytecode to be serialized > > > > 2. Serialize desugared Core into iface files (fat interfaces), so that > > (byte)code-gen can be restarted from this point and doesn't need > > > > (1) might be challenging, but offers a few more advantages over (2), > > in that we can reduce the work done to load TH-heavy codebases to just > > a load of the cached bytecode objects from disk, and could make the > > load process (and times) for these codebases directly comparable to > > their TH-free cousins. > > > > It would also make ghci startup a lot faster with a warm cache of > > bytecode objects, bringing ghci startup times in line with those of > > -fno-code > > > > However (2) might be much easier to achieve and offers many > > of the same advantages, in that we would not need to re-run > > the compiler frontend or core-to-core optimisation phases. > > There is also already a (slightly bitrotted) implementation > > of (2) thanks to the work of Edward Yang. > > > > If any of this sounds exciting to you as a student or a mentor, please > > get in touch. > > > > In particular, I think (2) is a feasible project that can be completed > > with minimal mentoring effort. However, I'm only vaguely familiar with > > the details of the byte code generator, so if (1) is a direction we want > > to pursue, we would need a mentor familiar with the details of this part > > of GHC. > > > > Cheers, > > Zubin > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs