Hi Johan, I cannot give an exact estimate on times because I'm not a true guru. But my main worry is that without substantial and directed effort, such an attempt would die rather quickly. In only the 4 years since Types are Calling Conventions was published, Core has changed a lot from my passenger-window-view, and there have been various overhauls in several parts of the optimizers. It's unclear if those would actually pose a problem, but it's just another thing to consider.
For another example that springs to mind, consider the Glorious New Code Generator. Since it's initial inception, the design and integration and finally switching it to the default (just 2-4 months ago!) took over 3 or 4 years as well. Yet the number of times the regular backend and C-- changed in theory/principle in this era was relatively small, compared to core. There was little momentum elsewhere, so 'keeping up' is easy. Despite that, it was a multi-pronged effort by several people and took years to get ready. Core is far more volatile than C--, and will see far more radical churn in the next 3 years as well, I'm sure. I suppose my direct point is: the actual *momentum* needed to both do this, and keep up with where GHC will be when you are done I think is tremendous without a substantial amount of help and dedicated focus. What I would like to know (and perhaps Max can chime in here,) is: is there any standalone implementation of Strict Core anywhere, worth playing with and experimenting upon? If I remember correctly, the TACC paper even leaves several important novel optimizations unspecified, such as the various arity-raising and deep unboxing optimizations. Implementing these will be another task, if they are to be a win. If we had a standalone implementation, I think it would not only help iron out some of the questions posed here like how the optimizations port over, it would also be substantially easier to approach and reason about (at the very least, due to not having to fight GHC so much initially.) Finally, I think it would be possible to hook this into GHC independently* to try it out as a prototype with little effort. Anyway, sorry for the ramblings. Again, I'm not the biggest guru here by a million miles, but I have seen a lot of GHC's evolution in the past, so I don't think I'm very far off the mark when I say it will be a lot of work. * In theory we can just do the exact same thing me and David Himmelstrup did with LHC years ago, but less of a hack. We can simply convert from GHC's core to a Strict Core we define independently. LHC did this by parsing external core and converting to GRIN, but now we have something better: Compiler plugins. I think it would be quite possible to write a plugin that replaces the entire Core2Core pipeline in the frontend with a "convert to StrictCore, optimize, convert back to ordinary core" function. This is very easy using plugins, and means we can purely see the win from using Strict Core, and take the time to port optimizations and see their effect. Ben L. also recently used a similar approach for Repa4, using the DDC core language instead. Max B. himself also did something similar in [1] using a core language that is both "simpler and more expressive than GHC Core," but the details are either left to the reader to decipher, or Max to explain... [1] https://github.com/batterseapower/cps-core On Thu, May 2, 2013 at 11:30 AM, Johan Tibell <johan.tib...@gmail.com> wrote: > Hi Simon and Max, > > I've been thinking about Strict Core quite a bit lately. I'd like to take a > stab at implementing it in GHC, if feasible. My motivations for implementing > Strict Core are > > generating faster code in a more robust manner, and > implementing strictness annotations at the type level in Haskell itself*. > > Now, I don't know how much work this will be. What's you best time estimate > (say, if you would do it vs if I would do it)? > > My plan would roughly be as follows: > > Create a branch to develop on. > Temporarily delete all the non-essential Core2Core transformations. This > will let us get to a place where we have a functional compiler using Strict > Core more quickly. > Change CoreSyn.Expr to be Strict Core. > Plumb the changes through the compiler until it compiles (and passes the > tests) again. > Once all tests pass, re-add all the Core2Core passes and make them use > Strict Core. > Rebase the commits so they can be merged nicely into the main branch. > > How does that sound? > > * I think this could be one of the most important changes in a long time to > help Haskell in the "real world". It gives us a better way to talk about > strictness than we have today, reducing time spent on chasing down space > leaks. One we have strictness annotations in type, we could experiment with > a Strict language pragma to make a whole module call-by-value. > > Cheers, > Johan > > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin - PGP: 4096R/0x91384671 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
