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> 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.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 >> slides: >> https://docs.google.com/presentation/d/1g_-bHgeD7lV4AYybnvjgkWa9GKuP6QFUyd26zpqXssQ/edit?usp=sharing >> >> Regards, >> Csaba >> _______________________________________________ >> 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