Mail Archives: djgpp/1998/11/16/03:18:46
On Sun, 15 Nov 1998 moshier AT mediaone DOT net wrote:
> : ``Long double'' and ``fast'' don't live together well enough ;-).
>
> In x86 coprocessors, not only the arithmetic but also the elementary
> functions like log and tan are computed in long double anyway,
> so there is essentially no speed difference.
True, but that's not what I meant.
Going to long double 80-bit format most probably won't solve any
significant problems in this case, since (a) many functions in the
posted snippet would be inlined by GCC (and thus execute at native
80-bit precision) anyway; and (b) AFAIK GCC holds intermediate results
on the FP stack in 80-bit format, unless told otherwise. Since the
offending computations, as we were told, run in the innermost loop,
I'm led to believe that most of that code uses 80-bit long doubles
already.
I was thinking about more than 80-bit precision, which would need to
be done in software and thus be slow. I'm sorry I used the confusing
term ``long double'' which obscured my idea.
> : The new libm from the beta release of v2.02 should be more accurate,
> : so you might give it a try.
>
> In many cases the new libm is actually less accurate than the
> coprocessor functions because the coprocessor results are long
> double but fdlibm was not designed to take advantage of long double.
The cited fragment made a comparison between the old libm.a from v2.01
(used by the original poster, as he told in his message) and the
version from recent v2.02 betas. Testing shows that the new version
is more accurate than the old one.
In fact, testing also shows that the new libm.a is more accurate than
the ANSI math functions which are part of libc.a. While it is true
that improved versions of those functions can be written using the
coprocessor, the current versions are less accurate than libm. Eric
Rudd is working on improved coprocessor-based versions, AFAIK.
- Raw text -