Unpack primitive types by default in data
axman6 at gmail.com
Fri Feb 17 01:52:22 CET 2012
Sounds like it's definitely worth playing with. I would hesitate to use the shootout benchmarks though, simply because anything there is already going to be unpacked to the hilt.
How difficult do you think it would be to implement this in GHC?
On 17/02/2012, at 11: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.
> 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
> 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