Unpacking across modules

[Scott Dillard]

On Nov 13, 2007 3:45 AM, Simon Marlow <simonmarhaskell at gmail.com> wrote:
>
> What you're seeing here is the magic of automatic specialisation.  When the
> Vec type and instances are in the same module as the use, GHC can see what
> type the instances are being used at, and can create specialised instances,
> which it does.  Then the strictness analyser kicks in and everything is
> unboxed.  When the use of the instance is in a separate module, GHC cannot
> specialise, because it doesn't know what type to specialise at.  If you add
> appropriate {-# SPECIALISE instance #-} pragmas in the POLY_OTHER case, you
> should be able to get good code.

Yes, SPECIALISE did the trick. Thanks. So, If I have a sizable library
using these kinds of data types, do I need to specialize only the
exported functions? Or do I also need to specialize the functions
internal to the library? As long as everything has inline pragmas, it
should only be necessary to specialize the exported functions,
correct?

>
> > PS: Also, when the INLINE pragma is used with the Storable instance
> > for the polymorphic data type, it causes heap explosion, even in the
> > same file. Any thoughts here?
>
> I suspect this is defeating the specialisation somehow, but I'm not sure.

It turns out it was the default definitions of peekElemOff and
pokeElemOff. I only defined peek and poke for my Storable instance,
but I used the ElemOff variants. When I provided definitions for those
functions as well, things sped right up.

Thanks for your help,
Scott