presentation: Next-gen Haskell Compilation Techniques

[Csaba Hruska]

Hi Sebastian,

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.

Cheers,
Csaba

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 [1]. 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 [2] 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 [3] 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!
> Cheers,
> Sebastian
>
> [1] https://gitlab.haskell.org/ghc/ghc/-/issues/19113
> [2]
> https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/spec-constr.pdf
> [3] https://arxiv.org/abs/1908.05647
>
> Am So., 10. Jan. 2021 um 00:31 Uhr schrieb Csaba Hruska <
> csaba.hruska at gmail.com>:
>
>> Hello,
>> 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
>> slides:
>> https://docs.google.com/presentation/d/1g_-bHgeD7lV4AYybnvjgkWa9GKuP6QFUyd26zpqXssQ/edit?usp=sharing
>>
>> Regards,
>> Csaba
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210111/f1eee803/attachment.html>