On Nov 13, 2007 3:45 AM, Simon Marlow
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