This is the mail archive of the 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]

Second Draft "Unsafe fp optimizations" project description.


Thanks for reiterating over this.

| Optimizations that change the meaning of floating point expressions

It would be more accurate and consistent with latter description to
say  "Transformations" instead of "Optimizations".

| Rationale
| Why would someone forego numerical accuracy for speed ? Isn't the fast but
| wrong answer useless ?
| Unfortunately, this simple reasoning doesn't cut it in the Real World. In
| the Real World, computational problems have been beaten on, simplified and
| approximated in a heroic attempt to fit them into limitations of present day
| computers. Especially the loss of accuracy due to these approximations could
| easily overwhelm that resulting from changing its floating point arithmetic
| slightly. The most obvious example of this is the first person shooting
| game: While the physics of reflection, refraction and scattering of
| electromagnetic radiation with wavelengths between 400 and 800 nm has been
| significantly approximated, what would make the game absolutely useless is
| the frequency of updating the image dropping below 20 per second.

I think the above description is somehow misleading.  

The loss of accuracy in tranforming expressions can be harmless or
acceptable if it does -not- excessively exceed the errors coming from 
approximating observables.  However, there are other problems coming
from the Real World where loss of accurary can be dramatic in their
resulting computations (the polynomials we deal with definitely come
from Real World).  So I don't think it is appropriate to say 
"this simple reasoning doesn't cut it in the Real World".

What about

  In numerical problems, there are roughly two kinds of computations: 
  1) those who need full precision in order to guarantee the results, and
  2) those which are less sensible to occasional loss of accuracy.

  For the latter category, it is reasaonable to forego the numerical
  accuracy for speed. 

in place of 

   Unfortunately, this simple reasoning doesn't cut it in the Real World. 



| Open issues
| We should come up with a classification for complex arithmetic too. Just A/B
| with A and B complex already has a couple of different possible evaluations.

We should also document cases where the transformations considered in
this project depend on targets.  For example, Power does its
floating point arithmetics in 64-bit whereas Sparc has two distinct
categories of floating point arithmetic instructions -- a target may
choose to use full 64-bits because it is faster (althought I doubt
that is the case on Sparcs).

-- Gaby

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