Will Partain <[EMAIL PROTECTED]> wrote on 11 September
> ...
> *If* it is true that the Integer-vs-Int speed penalty is 5x
> (sounds plausible to me...), then I agree that (perhaps)
> 2x-3x of that can be clawed back, with good engineering
> effort. But I'll be surprised if you're not still left with
> a 2x-3x speed penalty. Total *system* effects on real
> programs? -- not a clue :-)
What concerns Standard Haskell, i am sure it is right for it to put
type Int = Integer
Now, on Haskell-2.
Have the implementation possibilities to be ignored when formulating
the language? Probably, not.
First, Int has to detect overflow and break. Otherwise it fits for
almost nothing.
Then, if Integer can be optimized even to 3x on small numbers
relatively to Int with the overflow detection, then it would be a
relief to forget of Int and write, say,
Polynomial [(a,Integer)] ...
instead of Integral i => Polynomial [(a,i)] ...
"5x" observation came to this mail list from me.
Before i noticed 5x, how happy i was ignoring Int!
Last year some implementors had agreed that 5x looks true.
Some mathematician had said something like
"Integer is given by God, and the rest is of human".
But Int, it is probably of Devil. Look at this 5x temptation ...
"5x" was the *total time ratio for the task* of a matrix inversion for
a matrix with the items being the residues modulo p, p = 3,5,7:
Rs k p, k <- [0..(p-1)],
Rs k p :: Rs Int or Rs Integer.
The operations involved are +,-,*,quotRem for Int (Integer) - and
the very operations on the lists of items - for a matrix was
represented as [[a]]. quotRem had been often applied to prevent the
growth of intermediate operands (and Int overflow).
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
