Re: Re[2]: Lua5 / poor performance

[RLake@...]

Hi, Doug.

I don't know if you have been following this discussion on the mailing
list, but, honest, I do know how to use libraries. The point was a version
of frexp which was not dependent on external libraries and which was
"religious" in the sense that it knows nothing about number format and
conforms only to ANSI C.

I just took a look at the frexp's offered by newlib; the generic version
does bit manipulation of floats/doubles based on the assumption that they
are in IEEE-754 format. This may not be the case on a random machine
(although I agree that it is overwhelmingly likely) and certainly would not
be the case for a bignum implementation. There is one architecture-specific
implementation -- for the i386 -- which is essentially an IEEE-754 machine,
so it does not really add anything except speed. As far as I can see, the
implementation is identical to the current glibc in both cases, which is
not surprising really.

The version which I posted, while it is obviously slower, is pure ANSI C
and does not rely on any feature of floating point arithmetic except that
multiplicative overflow either generates infinity or the largest possible
floating point number. In fact, it will yield "correct" results even on
integer arithmetic (although only the exponent will really be correct). If
you knew the arithmetic were floating point, you could eliminate the
restriction easily enough by inverting numbers greater than 1, and then
inverting the result and negating the exponent. Or, if you happened to have
the largest representable number handy, you could pretest by doing a direct
comparison with it. Not having ANSI C handy, I don't know what it says
about multiplicative overflow or acquiring the largest representable
floating point number.

I do not propose the actual use of this frexp; I regard it as more or less
an intellectual curiosity. However, if you were backed to the wall and you
did not, for whatever reason, want to include any external library, it is
100% usable. I did some time tests on it this morning, out of curiosity,
and was pleasantly surprised to see that it is only about seven times
slower than the glibc frexp on numbers in the range (2^-512, 2^512) (on a
Pentium III running at about 930 MHz, it did 2.5 million frexp's per
second, and including the cost of a minimal for loop and subroutine call).
I thought it would be slower.

Rici.