Stop using "Int" for microsecond delays in "base"
Bas van Dijk
v.dijk.bas at gmail.com
Thu Mar 31 12:08:22 CEST 2011
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,
> Libraries mailing list
> Libraries at haskell.org
You may also want to read section 3.3 of:
(note though that this document is more than 2 years old)
More information about the Libraries