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

[Daniel Peebles]

ByteArray# is a GHC primitive. There is no Haskell code for it unless you
want to look at the compiler implementation. It also doesn't have a
null-like value, but I guess you could use an empty one?

Dan

On Thu, Mar 31, 2011 at 4:55 AM, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110331/71a2c18e/attachment.htm>