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@haskell.org <javascript:;> > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org <javascript:;> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users