Summary of containers patches

[Johan Tibell]

On Fri, Sep 24, 2010 at 1:35 PM, Simon Peyton-Jones
<simonpj at microsoft.com> wrote:
> | > Can you give some examples to back up this claim?  I am skeptical
> |
> | I can look into it again after ICFP.
> |
> | I did spend some time trying to tease apart the performance
> | improvements we got from inlining foldl'. From what I remember, the
> | biggest gain from inlining is that the higher-order argument is known,
>
> Ah yes! But that is *quite different* from specialising only on the *type*!

I know. I was just trying to be transparent by saying that *most* of
the speedup from inlining foldl' is not from unboxing. If I remember
correctly there was still *some* speedup from unboxing. That's all.

> | foldl' :: (a -> b -> a) -> a -> [b] -> a
> | foldl' = ...
> | {-# SPECIALIZABLE foldl' #-}
> |
> | and then have foldl' be specialized in the client module at whatever
> | type it's called at, but only once for each type (instead of once per
> | call site).
>
> For overloaded functions, that is precisely what I'm proposing.
>
> For foldl' I think you will get no benefit from specialising on the type; only from specialising on the actual function passed.  So in that case inlining probably really is the answer.

I used foldl' as an example.

My question is: are there any kind of functions, other than overloaded
functions, that would benefit from specialization. If the answer is
yes, can we apply the same heuristic you use for overloaded functions
to specialize these kind of functions. If we cannot automatically
detect all the cases where specializing would be beneficial, should we
allow the user to tell us when it might be beneficial?

-- Johan