Unpack primitive types by default in data
marlowsd at gmail.com
Fri Feb 17 13:40:48 CET 2012
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
> 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
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
GHC itself would be a good benchmark, incidentally...
> I imagine that ignoring UNPACK pragmas selectively wouldn't be too
> hard. Where the relevant code?
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users