This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Floating point trouble with x86's extended precision


On 21 Aug, Jim Wilson wrote:
> I don't do FP for a living, and I don't want to spend hours composing
> every response to this thread, so it is hard for me to be precise.

Thanks again for taking the time! I really appreciate it.

> I think it will also be hard for me to explain to you why there are
> problems with the x86.  It isn't clear to me that you have a good enough
> understanding of the issues involving numerical analysis on computers.

Numerical analysis is a wide field, and the requirement of the people
differ. Maybe they can be seperated into two groups:

(I)  Have full control over each calculation, know exactly where rounding
     takes place and to which precision (e.g. ensure that the rounding
     doesn't exceed 0.5 ulps).
(II) Use extended precision as long as possible and do rounding when it's
     inevitable (but it's not important whether the rounding error is 0.5
     ulps or even 1 ulp - as long as I did several computations before
     with extended precision).

I do numerical analysis for a living - fluid dynamics (CFD) to be precise.
In this field the discretizion error usually outweighs the rounding
error by magnitudes, so it doesn't really matter, if you round up to
0.5 ulps or 1 ulp every now and then. But still, extended precision
does you a favour when computing inner products of large vectors.
(Maybe that's what Intel had in mind when designing their FPU.
I really get better results with x86 than with MIPS for example.)
So this community favors (II).

Doing things like interval arithmetic probably requires (I) -
this is of course just an example.

Being biased towards (II) I probably underestimated the importance of
(I) for many - I want to apologize for this.


What does that mean for GCC?
============================

The fact we have to face is, that the x86 architecture much better
supports (II), and that it's almost impossible to really do (I)
without doing it in software completely (ungh!).

>From the perspective of (II), GCC does its job nicely and is not buggy
at all. (There are some caveats, though - but they stem from underlying
design of the arithmetic and not from GCC.)

>From the perspective of the CFD community the code needs to be fast.
I mean really fast. Halving the performance just to get some different
fraction of a ulp is not an option for this community. Then they'd
consider GCC broken.


>From the perspective of (I), GCC is broken, alas. There are some work-arounds
like "-ffloat-store", but none of the workarounds gets it really correct.


In conclusion we can do two things IMHO:
* Try to *also* support (I) on x86 (if there are any volunteers).
  But please make this optional, because (II) still is an important goal.
* Document the current situation in one place to help avoid confusion.


To make things short, I'll try to sum things up for inclusion in the
GCC documentation (be it *.texi or *.html) and show *both* sides.
Since the topic is somewhat complicated it probably won't fit on the
bugs.html page (where the whole thing started), but there should be a
pointer from there.
But don't expect that to come soon, because I want to clean up the
rest of the bug reporting instructions first.

Thanks to everybody who took the time and tried to put some light into
the topic!

Regards,
Volker



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]