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*: Gabriel Dos Reis <gdr at codesourcery dot com>*Subject*: Re: What is acceptable for -ffast-math? (Was: associative law in combine)*From*: Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>*Date*: Wed, 01 Aug 2001 20:21:03 +0200*Cc*: dewar at gnat dot com, amylaar at redhat dot com, aoliva at redhat dot com, gcc at gcc dot gnu dot org, moshier at moshier dot ne dot mediaone dot net, torvalds at transmeta dot com, tprince at computer dot org

gdr@codesourcery.com said: > No, I do mean a transformation which does not dramatically transmute > the computations. That's not a definition. Dramatically, can mean very different things depending on the people and on the algorithms. That's basically the point that I'm trying to make. In many applications and algorithm the optimization a/b/c to a/(b*c) is meaningful and relevant. Not everyone will have floats that are 2*sqrt(DOUBLE_MAX) (or any other combination that might overflow). Actually, a lot of people use a representation to make computation that is much wider than the accuracy of the input and the accuracy you can get on the output. Let's face it, there are two ways of using floats. 1) you take enough margin to not care about the accuracy problems (ie you take several bits more than ``needed''), and then want to write your program as naturally as possible and expect the compiler to do what is possible for the computation to be as fast as possible. 2) You are constrained either by the accuracy you would like to get or by the size of your data. Then you tend to write without these extra bits and pay much more attention to the rounding effects. NONE OF THE MODELS IS BETTER THAN THE OTHER. There should be support in gcc for both communities. You can argue that wanting to speed up a computation made with doubles that could have been with simple floats is stupid, but: a) double are often as fast or even faster than floats. Until fairly recently, a lot of processor were doing float computation by truncating the results of a double computation. Recent Sparc processor indeed have hardware floats, that go faster than doubles but not 2 times IIRC. b) Writing code that extracts every single possible bit of accuracy tends to be very difficult to understand and maintain (see eg DNRM2 or FNRM2 in blas that just computes the Euclidean norm of a vector and you will understand what I mean. By the way, I'm sure that nowadays, implementing FNMR2 with double would be faster at the same accuracy and much simpler to maintain. For DNMR2 things are more compilcated as we would have to switch to long double with which I have little experience). The fact that "95% of the folks out there are completely clueless about floating point. (J.G. 28 Feb. 1998)" have to be taken into account. For at least quite many of those 95%, floating point works because they are not experiencing the "bounds" of floting point and merely stay in the safe area provided by the extra bits of accuracy. By the way the previous sentence is cited in a report of Kahan and Darcy about "Java floating point", where they also state the rule (that can be broken eventually): "Evaluate arithmetic expressions and, except possibly for gargantuan arrays, declare temporary (local) variable ALL with the widest finite precision that is not too slow nor too narrow." > Where did you get the idea that I meant "mathematically provable safe > optimisation"? First to be sure we understand each other, by mathematically here, I reasonning in a mathematical fashion using the rules governing floating point computation and trying to assert that two different expressions will give the same result. That is exactly your point, no. You do not want to allow optimisations that would not lead to the same results in boundary situations (and again, I agree that this is perfectly fine for some community of users, my point is that there is another communitie which does not care). > Going into abstract considerations like NP-completness is beside the > point. Agreed, I was not going into such considerations. -------------------------------------------------------------------- Theodore Papadopoulo Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01 --------------------------------------------------------------------

**Follow-Ups**:**Re: What is acceptable for -ffast-math? (Was: associative law in combine)***From:*Gabriel Dos Reis

**References**:**Re: What is acceptable for -ffast-math? (Was: associative law in combine)***From:*Gabriel Dos Reis

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

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