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

[Bas van Dijk]

On 31 March 2011 10:55, wren ng thornton <wren at freegeek.org> wrote:
> On 3/30/11 2:00 PM, Johan Tibell wrote:
>>
>> On Wed, Mar 30, 2011 at 7:56 PM, Evan Laforge<qdunkan at gmail.com>  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 at 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