More speed please!

[Josef Svenningsson]

On 5/11/07, Simon Peyton-Jones <simonpj at microsoft.com> wrote:
> | I'm replying to a rather old thread here, about unboxing in functions. Duncan
> | had a continuation monad which passed around some data type that would be nice
> | to unbox. You discussed strictness annotations in function types as a potential
> | solution. I have a different tack on the problem which seems potentially
> | useful. I've experimented with doing local defunctionalization on the module.
>
> Interesting suggestion, Josef.  In general, local defunctionalisation would be an intersting transformation to try. I'm not sure how well it would scale: the larger the scope, the bigger the more distinct functions and the bigger the dispatch table.
>
Indeed the dispatch table could grow big, but I'm not sure it would be
a scalability problem.  Note that all the code that goes in to these
dispatch tables (I call them apply functions) are ripped out from
other places in the program. So there is really no new code being
added, it's only shuffled around.

On the other hand I don't know how GHC deals with large case
expressions and if they are a problem, be it that they can increase
the compilation time or the runtime of the program, then there might
of course be a problem.

> Also your transformation is semantically transparent (no effect) whereas Duncan is prepared to add ! annotations that really make things stricter, just as ! annotations in data type decls do today.  So presumably he will get further than you will, because he is making more assumptions.
>
Indeed. But I think the main advantage for Duncan's approach, over
local defunctionalization, is its general applicability. Local
defunctionalization only kicks in under very special circumstances and
even then isn't always a net win (or so my intuition tells me). The
bang annotations otoh can be inserted wherever you like and would
presumably work transparently across module borders.

>
> Meanwhile, I've thought a bit more about Duncan's idea.  One attractive aspect is that you can regard it as a direct extension of Haskell's existing mechanism of ! on data types, making the {-# UNPACK #-} pragma look inside function types as well as looking inside data types.  I like that. It makes it sounds less ad hoc than I previously thought.  I'll open a Trac ticket for this thread, http://hackage.haskell.org/trac/ghc/ticket/1349
>
Sounds good! It would be a cool thing to have. I'm looking forward to
seeing it implemented in GHC :-)

Cheers,

Josef