A more clever representation of Integer could unbox numbers in big range. But that would require some runtime support, I think. -- Lennart 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 this. 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 2.55
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 primitives.
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 optimisations.
So as I said, the ratio really does depend on what you're doing.
Duncan
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users