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.
Right - but some optimisations absolutely require whole-program analysis, don't 
they?  I'm thinking of flow analyses that support defunctionalisation, when you 
must know all the lambdas that could be bound to `f` in the definition of `map` 
for example.

Such optimisations are powerful, but brittle because they are simply 
inapplicable without whole-program analysis.  Or maybe you can find ways to 
make them more resilient.

Simon

From: ghc-devs <ghc-devs-boun...@haskell.org> On Behalf Of Csaba Hruska
Sent: 11 January 2021 12:19
To: Sebastian Graf <sgraf1...@gmail.com>
Cc: GHC developers <ghc-devs@haskell.org>
Subject: Re: presentation: Next-gen Haskell Compilation Techniques

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 
<sgraf1...@gmail.com<mailto:sgraf1...@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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F19113&data=04%7C01%7Csimonpj%40microsoft.com%7C0a889669aa404e4b938008d8b62b23f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637459644503167010%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0W9ejmKCDKpuBT0mEArvIwAmHDUS4QI9kc5j%2BhGUX5I%3D&reserved=0>
[2] 
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/spec-constr.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fresearch%2Fwp-content%2Fuploads%2F2016%2F07%2Fspec-constr.pdf&data=04%7C01%7Csimonpj%40microsoft.com%7C0a889669aa404e4b938008d8b62b23f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637459644503177005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8wJJXOpNuaQpjOWBTwbQ0upeOj1LLXSUD86cn8TbKI8%3D&reserved=0>
[3] 
https://arxiv.org/abs/1908.05647<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fabs%2F1908.05647&data=04%7C01%7Csimonpj%40microsoft.com%7C0a889669aa404e4b938008d8b62b23f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637459644503186998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=LCFO8R5SZT0KveoB9GyPcMpwbhU9DTLOnYhxD%2FZNXxU%3D&reserved=0>

Am So., 10. Jan. 2021 um 00:31 Uhr schrieb Csaba Hruska 
<csaba.hru...@gmail.com<mailto:csaba.hru...@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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DjyaR8E325ok&data=04%7C01%7Csimonpj%40microsoft.com%7C0a889669aa404e4b938008d8b62b23f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637459644503196994%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dbxjJKAKqZJZ2jdYE2aR6ymQIp9awCmOHwsBAHLz9AM%3D&reserved=0>
slides: 
https://docs.google.com/presentation/d/1g_-bHgeD7lV4AYybnvjgkWa9GKuP6QFUyd26zpqXssQ/edit?usp=sharing<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fpresentation%2Fd%2F1g_-bHgeD7lV4AYybnvjgkWa9GKuP6QFUyd26zpqXssQ%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7C0a889669aa404e4b938008d8b62b23f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637459644503196994%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UHHOI6Nr80zuDrFDPVUz6wsNXKlxY06%2B5tG%2BCxf847I%3D&reserved=0>

Regards,
Csaba
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=04%7C01%7Csimonpj%40microsoft.com%7C0a889669aa404e4b938008d8b62b23f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637459644503206993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BAdAJUowngbDQt7BMX43JegOeUNMfh%2B00VYYBVyTPN0%3D&reserved=0>
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Reply via email to