Re: Stop using "Int" for microsecond delays in "base"

On 31 March 2011 10:55, wren ng thornton wrote:

On 3/30/11 2:00 PM, Johan Tibell wrote:

...

On Wed, Mar 30, 2011 at 7:56 PM, Evan Laforge  wrote:

...

It's good for big data structures since it can be unpacked into the constructor.  I've seen space usage go down by 1/3 after an Integer -> Int switch.  Integer is a sum type so there's an extra two words of overhead (if not mistaken, one for the tag, and one for the indirection since it can't unpack).

Yes. Integer is terrible for performance.

This makes me wonder, though, whether it'd be worthwhile to:

(A) make a special case allowing unpacking of Integers (e.g., by storing the constructor tag adjacent to the payload, ala PiSigma), or

(B) to simplify the implementation to

   data Integer = J# Int# ByteArray#

where the current (S# (x::Int#)) is implemented by (J# x nullPtr) or whatever the equivalent is for ByteArray#s ---Hackage doesn't want to show me the source for what a ByteArray# actually is implemented as...

I could see the PiSigma implementation of A causing a lot of ruckus throughout the runtime, which would be a good reason to rule that out.

But I can't see why B hasn't been done ---even if just as an implementation of A! It increases the memory footprint for Int-sized Integers, which is unfortunate, but the check for null should be no more expensive than the case match, and it opens the way for unpacking and related optimizations (which would offset or reverse the memory footprint differences).

-- Live well, ~wren

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

You may also want to read section 3.3 of: http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes (note though that this document is more than 2 years old) Bas