Unpack primitive types by default in data

[Don Stewart]

Couldn't you measure it by changing base to use data Int = I# {-# UNPACK
#-} Int# and see what happens?

On Thursday, February 16, 2012, Alex Mason wrote:

> Hi Johan,
>
> 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?
>
> Cheers,
> Alex
>
> 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
> > 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.
> >
> > 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 <javascript:;>
> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20120216/35fdd373/attachment.htm>