Sigbjorn Finne <[EMAIL PROTECTED]> writes:
> > 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.
No, unrolling does not speed up this case. For the case of addition
of Int-sized numbers, a "rolled" (i.e., not unrolled; is there a word
for this?) loop would be a fair bit faster; the above would reduce to:
> > It sets up various registers (size, and pointers to
> > source1, source2, and destination).
> > It does the addition.
I looked at the code for div; yes, it does handle Int-sized divisors,
but doesn't do anything special for Int-sized dividends, so you still
have annoying loops, etc. for the Int-sized case, as well as several
function calls. I bet that just adding a conditional:
if (abs_usize == 1 && abs_vsize == 1) {
/* do special-case code */
}
at the beginning of each of the mpz_*() functions would speed up
Int-sized operations by an order of magnitude, at the cost of a few
percent slowdown on operations that were bigger than an Int.
> 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.
I'm glad to hear it; do you have anything written on exactly how you
this will work?
> It'll be interesting to see the bottom line NoFib figures with this
> change of representation in place.
Yes, it will.
Carl Witty
[EMAIL PROTECTED]
