Re: Strange math library results on i386-linux

[Roger Sayle <roger at eyesopen dot com>]

> Indeed, when I compiled his tests using -O0, the results were quite
> (very) good, except for sin, cos, tan (for lack of perfect argument
> reduction) and j0, j1, gamma, lgamma, y0, and y1 (that I don't really
> care about for the moment, they seem all to have to do with argument
> reduction and/or handling of results close to the maximum flonum).

I wonder if you could also add directories to your ~lucier/fun-test/
pages, that show the effects of -D__NO_MATH_INLINES.  Looking at
glibc's headers there are a number of intrinsics that are inlined
by "#ifdef __OPTIMIZE__" that may need to guarded by "#ifdef
__FAST_MATH__", which might explain some of the loss of precision
between -O0 and -O1.

The lack of argument reduction in "sin", "cos" and "tan" would
appear to be a feature of their implementation in the i387.  It
might be worthwhile comparing different athlon and pentium chips.

Its also worth timing/evaluating some of glibc's generic "ieee754"
implementations on IA-32 (based upon IBM's accurate math library)
rather than the i387 intrinsic versions in "i386/fpu" that are
currently used.  As Richard Henderson pointed out to me, Intel's
own documentation recommends using software methods if less than
extended precision accuracy is required.  So if software methods
are competitive with the hardware instructions, and the hardware
instructions have questionable accuracy, it might just be a matter
of getting glibc to use the generic implementations on i386.
This will treat i386 like every other platform with respect to FP
implementation, and just ignore some of the additional instructions
that are available.

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833