presentation: Next-gen Haskell Compilation Techniques
csaba.hruska at gmail.com
Mon Jan 11 12:18:37 UTC 2021
Thanks for your feedback.
I know that CIB and Perceus have issues with cycles, but these systems are
still in development so who knows what will be the conclusion.
I may not emphasize in the talk, but the goal of the grin compiler project
is to build a compiler pipeline that allows easy experimentation of
different compilation techniques. Anything between whole program
compilation to per module incremental codegen. So the whole program
compilation is not really a requirement but an option.
On Sun, Jan 10, 2021 at 1:58 PM Sebastian Graf <sgraf1337 at gmail.com> wrote:
> Hi Csaba,
> Thanks for your presentation, that's a nice high-level overview of what
> you're up to.
> A few thoughts:
> - Whole-program optimization sounds great, but also very ambitious,
> given the amount of code GHC generates today. I'd be amazed to see advances
> in that area, though, and your >100-module CFA performance incites hope!
> - I wonder if going through GRIN results in a more efficient mapping
> to hardware. I recently found that the code GHC generates is dominated by
> administrative traffic from and to the heap . I suspect that you can
> have big wins here if you manage to convey better call stack, heap and
> alias information to LLVM.
> - The Control Analysis+specialisation approach sounds pretty similar
> to doing Constructor Specialisation  for Lambdas (cf. 6.2) if you also
> inline the function for which you specialise afterwards. I sunk many hours
> into making that work reliably, fast and without code bloat in the past, to
> no avail. Frankly, if you can do it in GRIN, I don't see why we couldn't do
> it in Core. But maybe we can learn from the GRIN implementation afterwards
> and maybe rethink SpecConstr. Maybe the key is not to inline the function
> for which we specialise? But then you don't gain that much...
> - I follow the Counting Immutable Beans  stuff quite closely
> (Sebastian is a colleague of mine) and hope that it is applicable to
> Haskell some day. But I think using Perceus, like any purely RC-based
> memory management scheme, means that you can't have cycles in your heap, so
> no loopy thunks (such as constant-space `ones = 1:ones`) and mutability. I
> think that makes a pretty huge difference for many use cases. Sebastian
> also told me that they have to adapt their solutions to the cycle
> restriction from time to time, so far always successfully. But it comes at
> a cost: You have to adapt the code you want to write into a form that works.
> I only read the slides, apologies if some of my points were invalidated by
> something you said.
> Keep up the good work!
>  https://gitlab.haskell.org/ghc/ghc/-/issues/19113
>  https://arxiv.org/abs/1908.05647
> Am So., 10. Jan. 2021 um 00:31 Uhr schrieb Csaba Hruska <
> csaba.hruska at gmail.com>:
>> I did an online presentation about Haskell related (futuristic)
>> compilation techniques.
>> The application of these methods is also the main motivation of my work
>> with the grin compiler project and ghc-wpc.
>> video: https://www.youtube.com/watch?v=jyaR8E325ok
>> ghc-devs mailing list
>> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs