Carl R. Witty writes:
> Will Partain <[EMAIL PROTECTED]> writes:
>
> > [EMAIL PROTECTED] writes:
> >
> > > ... The question is of performance for Int sized things in
> > > Integer, so the fact that you call a good library isn't
> > > relevant; what's important is what you do when you don't
> > > _need_ to use GMP to get the answer.
> >
> > It is relevant, because (unless my memory has faded badly...)
> > the GMP folks optimize (you know, um, hand-tuned assembly
> > language... :-) for the common case, which is Int-sized
> > things in Integers.
>
> I've just spent a fair bit of time looking through this code, and I
> can't see any such optimization.
>
[list of Integer addition steps deleted]
> This wants to add two 1-word numbers in a fast, unrolled loop.
> It sets up various registers (size, and pointers to
> source1, source2, and destination).
> It computes the number of complete times to go through the
> loop (0).
> It computes the location to jump into the middle of the loop,
> to handle the one word.
> It adjusts the various pointer registers to compensate for the
> fact that it's jumping into the middle of the loop.
> It jumps into the middle of the loop.
> It does the addition.
So, unrolling the loop in hand coded assembly does speed it up, no?
The MP_INT representation doesn't particularly accommodate the kinds
of code optimisations I believe you're looking for, but the GMP code
does consider 'the Int case' specially in a number of places; look at
the code for div&mod, for instance.
Clearly there's a range of optimisations possible here; using an
efficiently implemented bignum library being one (not irrelevant) way
to improve matters. Changing the representation of Integer is another,
distinguishing at the Haskell level between ones that fit in a machine
word and those that don't. We plan to use such a representation for
GHC/Hugs.
It'll be interesting to see the bottom line NoFib figures with this
change of representation in place.
--Sigbjorn
