Unpack primitive types by default in data

[Simon Marlow]

On 17/02/2012 00:25, Johan Tibell wrote:
> Hi all,
>
> I've been thinking about this some more and I think we should
> definitely unpack primitive types (e.g. Int, Word, Float, Double,
> Char) by default.

Why only primitive types?  I think you probably want to do it for any 
type that unpacks to a single word (or maybe at most 2 words? another 
thing to tune).

> The worry is that reboxing will cost us, but I realized today that at
> least one other language, Java, does this already today and even
> though it hurts performance in some cases, it seems to be a win on
> average. In Java all primitive fields get auto-boxed/unboxed when
> stored in polymorphic fields (e.g. in a HashMap which stores keys and
> fields as Object pointers.) This seems analogous to our case, except
> we might also unbox when calling lazy functions.
>
> Here's an idea of how to test this hypothesis:
>
>   1. Get a bunch of benchmarks.
>   2. Change GHC to make UNPACK a no-op for primitive types (as library
> authors have already worked around the lack of unpacking by using this
> pragma.)
>   3. Run the benchmarks.
>   4. Change GHC to always unpack primitive types (regardless of the
> presence of an UNPACK pragma.)
>   5. Run the benchmarks.
>   6. Compare the results.
>
> Number (1) might be what's keeping us back right now, as we feel that
> we don't have a good benchmark set. I suggest we try with nofib first
> and see if there's a different and then move on to e.g. the shootout
> benchmarks.

nofib probably has, to a first approximation, zero strictness 
annotations.  Because most of the programs in there predate the addition 
of strictness annotations to Haskell.

But I think the approach of ignoring UNPACK pragmas first is the right 
one - otherwise we have no way to get good data about how useful it is 
to add it automatically.  It's just a question of finding some good 
benchmarks then.

GHC itself would be a good benchmark, incidentally...

Cheers,
	Simon



> I imagine that ignoring UNPACK pragmas selectively wouldn't be too
> hard. Where the relevant code?
>
> Cheers,
> Johan
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users