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] |

*To*: Toon Moene <toon at moene dot indiv dot nluug dot nl>*Subject*: Second Draft "Unsafe fp optimizations" project description.*From*: Gabriel Dos_Reis <gdosreis at sophia dot inria dot fr>*Date*: Sun, 5 Aug 2001 22:15:45 +0200 (MEST)*Cc*: gcc at gcc dot gnu dot org*References*: <3B6D9A51.26764131@moene.indiv.nluug.nl>

Toon, 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

**Follow-Ups**:**Re: Second Draft "Unsafe fp optimizations" project description.***From:*Toon Moene

**References**:**Second Draft "Unsafe fp optimizations" project description.***From:*Toon Moene

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |