Strict Core? - Haskell-Cafe - Haskell.org

newer
Haskell Front Page Ideas

Strict Core?

older
Heterogenous network stream

Gregory Crosswhite

15 Oct 2010 15 Oct '10

5:27 p.m.

Hey everyone, Out of curiosity, are there any plans for GHC to eventually use the Strict Core language described in http://www.cl.cam.ac.uk/~mb566/papers/tacc-hs09.pdf? Cheers, Greg

Reply

Sign in to reply online Use email software

Show replies by date

Andrew Coppin

15 Oct 15 Oct

6:01 p.m.

On 15/10/2010 10:27 PM, Gregory Crosswhite wrote:

Hey everyone,

Out of curiosity, are there any plans for GHC to eventually use the Strict Core language described in http://www.cl.cam.ac.uk/~mb566/papers/tacc-hs09.pdf?

Is that because I just mentioned the paper? Regardless, I'd be quite interested in the answer too. The paper looks quite promosing...

Reply

Sign in to reply online Use email software

Gregory Crosswhite

6:10 p.m.

Yes, I had seen this paper before and wondered the same thing at the time, but it was only just now when you brought the paper up that I realized I could ask people about it here. :-) On 10/15/2010 03:01 PM, Andrew Coppin wrote:

On 15/10/2010 10:27 PM, Gregory Crosswhite wrote:

...
Hey everyone,

Out of curiosity, are there any plans for GHC to eventually use the Strict Core language described in http://www.cl.cam.ac.uk/~mb566/papers/tacc-hs09.pdf?

Is that because I just mentioned the paper?

Regardless, I'd be quite interested in the answer too. The paper looks quite promosing...

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply

Sign in to reply online Use email software

Andrew Coppin

6:21 p.m.

On 15/10/2010 11:10 PM, Gregory Crosswhite wrote:

Yes, I had seen this paper before and wondered the same thing at the time, but it was only just now when you brought the paper up that I realized I could ask people about it here. :-)

I wonder if anybody has a list somewhere of "really cool stuff that we'd love to add to GHC if only we weren't constantly snowed under with PowerPC linker glitches and obscure type system errors"... ;-)

Reply

Sign in to reply online Use email software

Luke Palmer

7:25 p.m.

On Fri, Oct 15, 2010 at 4:21 PM, Andrew Coppin wrote:

On 15/10/2010 11:10 PM, Gregory Crosswhite wrote:

...
Yes, I had seen this paper before and wondered the same thing at the time, but it was only just now when you brought the paper up that I realized I could ask people about it here. :-)

I wonder if anybody has a list somewhere of "really cool stuff that we'd love to add to GHC if only we weren't constantly snowed under with PowerPC linker glitches and obscure type system errors"... ;-)

I think a more appropriate description of the list would be: really cool stuff that we'd love to add to GHC if only we weren't constantly busy adding other cool stuff. GHC Team++. Luke

Reply

Sign in to reply online Use email software

Max Bolingbroke

16 Oct 16 Oct

4:57 a.m.

Hi Gregory, On 15 October 2010 22:27, Gregory Crosswhite wrote:

Out of curiosity, are there any plans for GHC to eventually use the Strict Core language described in http://www.cl.cam.ac.uk/~mb566/papers/tacc-hs09.pdf?

I do not have plans to add it. I think it would be worth it - perhaps worth a few % points in runtime - but I've started researching supercompilation instead, which has more impressive effects :-) Simon has said he is keen to use it though - it's just a big engineering task to replumb GHC to use it, so perhaps this is a project for an enterprising student. That said, I've been told that UHC's core language uses the ideas from Strict Core, and they have/had a student at Utretch (Tom Lokhorst) who was working on implementing optimisations like arity raising and deep unboxing for the language. Cheers, Max

Reply

Sign in to reply online Use email software

Atze Dijkstra

1:21 p.m.

Hi, UHC indeed has an experimental typed core, which includes strict core (and is also based on GHC's core, and Henk). However, for UHC it is also quite a bit of engineering to make it produce typed/strict core for all language features, especially since it has to come from untyped core generation. So, there is currently a translation for a small set of language features, enough to do some experimenting, done by Tom Lokhorst. The current state is maintained and kept alive to allow further development in the future, e.g. both core structures internally have been put behind a class interface as to allow sharing of much of the generation infrastructure, but this all is still in transit and unfinished. cheers, On 16 Oct, 2010, at 10:57 , Max Bolingbroke wrote:

Hi Gregory,

On 15 October 2010 22:27, Gregory Crosswhite wrote:

...
Out of curiosity, are there any plans for GHC to eventually use the Strict Core language described in http://www.cl.cam.ac.uk/~mb566/papers/tacc-hs09.pdf?

I do not have plans to add it. I think it would be worth it - perhaps worth a few % points in runtime - but I've started researching supercompilation instead, which has more impressive effects :-)

Simon has said he is keen to use it though - it's just a big engineering task to replumb GHC to use it, so perhaps this is a project for an enterprising student.

That said, I've been told that UHC's core language uses the ideas from Strict Core, and they have/had a student at Utretch (Tom Lokhorst) who was working on implementing optimisations like arity raising and deep unboxing for the language.

Cheers, Max _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

- Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \ Fax : +31-30-2513971 .... | Email: atze@cs.uu.nl ............ / |___\

Reply

Sign in to reply online Use email software

Andrew Coppin

2:27 p.m.

On 16/10/2010 09:57 AM, Max Bolingbroke wrote:

I do not have plans to add it. I think it would be worth it - perhaps worth a few % points in runtime - but I've started researching supercompilation instead, which has more impressive effects :-)

From what I've seen, strict core makes several things simpler and easier to do. So it's not just about how much it speeds up the compiled code; it has the potential to make the compiler implementer's job easier.

Simon has said he is keen to use it though - it's just a big engineering task to replumb GHC to use it, so perhaps this is a project for an enterprising student.

...easier, that is, if you were writing it from scratch. Of course, any non-trivial alteration to a large existing codebase is usually a fair bit of work, but *especially* if you're changing really fundamental assumptions that pervade the entire thing...

Reply

Sign in to reply online Use email software

Stefan Monnier

17 Oct 17 Oct

2:23 p.m.

That said, I've been told that UHC's core language uses the ideas from Strict Core, and they have/had a student at Utretch (Tom Lokhorst) who was working on implementing optimisations like arity raising and deep unboxing for the language.

Many/most implementations of ML-ish languages use a similar approach. E.g. SML/NJ's Flint internal language is fairly similar to Strict Core (except for the lack of memoization of zero-arg functions, since that's not very often useful in the context of a strict language like SML) and uses the same kind of wrapper+inlinling to perform most of its optimizations. Note that in my experience working on SML/NJ's optimizer (using wrapper+inlining), such an approach to code transformation doesn't care about types at all, and indeed most/all of what tacc-hs09.pdf presents is mostly unrelated to whether the language is typed: e.g. the uncurrying of the zipWith higher-order argument is performed by the inliner (when inlining the various wrappers) without paying any attention to types. So types do not enable the optimization of higher-order functions: it's the wrapper+inlining strategy that enables it. Admittedly, the use of a statically typed intermediate language makes it easier to catch bugs in such optimization phases. Stefan

Reply

Sign in to reply online Use email software

Tom Lokhorst

4:11 p.m.

Note that in my experience working on SML/NJ's optimizer (using wrapper+inlining), such an approach to code transformation doesn't care about types at all, and indeed most/all of what tacc-hs09.pdf presents is mostly unrelated to whether the language is typed: e.g. the uncurrying of the zipWith higher-order argument is performed by the inliner (when inlining the various wrappers) without paying any attention to types. So types do not enable the optimization of higher-order functions: it's the wrapper+inlining strategy that enables it. Admittedly, the use of a statically typed intermediate language makes it easier to catch bugs in such optimization phases.

In the Strict Core language, laziness and the arity of a function is part of its type, so in that sense it cares about the type. For the uncurrying of zipWith, arity-information is of course very important. But you are right that apart from laziness, arity, and position of the function arrows, the base types aren't all that interesting. If all Int and Char types were replaced with (), most transformations would still work. The only transformation that actively uses type information is the deep unboxing transformation. It uses information about the shape of the data type to create a more optimal worker function. Sum types aren't explored in depth in the paper, and I haven't done so yet either in my work on UHC, but my hope is that those can also be optimized using the typed representation. - Tom Lokhorst P.S. I'm interested in learning more about Flint, can you recommend any further reading? On 17 October 2010 20:23, Stefan Monnier wrote:

...
That said, I've been told that UHC's core language uses the ideas from Strict Core, and they have/had a student at Utretch (Tom Lokhorst) who was working on implementing optimisations like arity raising and deep unboxing for the language.

Many/most implementations of ML-ish languages use a similar approach. E.g. SML/NJ's Flint internal language is fairly similar to Strict Core (except for the lack of memoization of zero-arg functions, since that's not very often useful in the context of a strict language like SML) and uses the same kind of wrapper+inlinling to perform most of its optimizations.

Note that in my experience working on SML/NJ's optimizer (using wrapper+inlining), such an approach to code transformation doesn't care about types at all, and indeed most/all of what tacc-hs09.pdf presents is mostly unrelated to whether the language is typed: e.g. the uncurrying of the zipWith higher-order argument is performed by the inliner (when inlining the various wrappers) without paying any attention to types. So types do not enable the optimization of higher-order functions: it's the wrapper+inlining strategy that enables it. Admittedly, the use of a statically typed intermediate language makes it easier to catch bugs in such optimization phases.

Stefan

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply

Sign in to reply online Use email software

5332

Age (days ago)

5334

Last active (days ago)

Download

9 comments

7 participants

tags

participants (7)

Andrew Coppin
Atze Dijkstra
Gregory Crosswhite
Luke Palmer
Max Bolingbroke
Stefan Monnier
Tom Lokhorst