Implementing Strict Core

[Austin Seipp]

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.tibell at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,
Austin - PGP: 4096R/0x91384671