returning to cost of Integer
lennart at augustsson.net
Mon Jul 31 20:13:40 EDT 2006
A more clever representation of Integer could unbox numbers in big
But that would require some runtime support, I think.
On Jul 31, 2006, at 11:19 , Duncan Coutts wrote:
> On Mon, 2006-07-31 at 14:32 +0400, Serge D. Mechveliani wrote:
>> Dear GHC developers,
>> Long ago you wrote that GHC has made Integer only about 3/2 times
>> slower than Int.
>> I tested this once, and then all this time I have been relying on
>> Now, with
>> ghc-6.4.1 compiled for Linux - i386-unknown,
>> running under Debian Linux, Intel Pentium III
>> under ghc -O,
>> I have an occasion to repeat the test on a certain simple program for
>> processing lists of length 7 over Integer.
>> And Integer shows 2.55 times slower (11.2 sec against 4.4).
>> Showld we somehow agree that
>> cost(Integer)/cost(Int) in GHC is about
>> or maybe we are missing something?
> The cost difference is varies with the context. In the case that the
> Int/Integer is always boxed then we might expect a constant factor
> between Int and Integer (at least for numbers that fit in an Int).
> However because Int is often unboxable where as Integer is never
> unboxable there are certainly programs where the factor is much much
> greater than x2 or x3. If the Int can be unboxed into an Int# then the
> operations are very quick indeed as they are simple machine
> As an extreme example, I just tried with one of my current simple
> ByteString benchmarks. If we swap Int for Integer in the inner loop of
> ByteString.map then the time to evaluate (map f . map g) s
> increases by
> 37 times!
> So actually that's not to say that Integer is slow, but rather that in
> many cases GHC is really pretty good at optimising right down to
> the low
> level details. The representation of Integer prevents many of these
> So as I said, the ratio really does depend on what you're doing.
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users