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: GCC beaten by ICC in stupid trig test!


Per Abrahamsen wrote:

Not really, the sin**2+cos**2 may often be more readable

Claiming that sin**2+cos**2 is more readable than 1.0 is really a very marginal argument, especially since the former raises the issue of whether you mean 1.0, or the actual value computed by this formula. If you want 1.0, say so.

and may be
hidden behind some inlined functions.

All the more reason not to perform inappropriate optimziations


Please do not assume that "real arithmetic" optimizations have already
been performed by the programmer by hand.

The other view point here is "please don't assume the programmer is incompetent and does not know what he is doing. Floating-point operations are precisely defined in IEEE and if I am a serious fpt programmer, I write the computations I want, and I do not want the compiler substituting arbitrary non-equivalent expressions.

And please do not
discourage people from implementing them.  If you must, insist they
are only enabled by a flag for use by those of us who want the
compiler to do such optimizations.

It's OK by me (though I consider it dubious and useless) to have such optimizations around. It is absolutely essential that it be possible to disable them.

I suppose that for people writing casual fpt code without error
analysis assuming that it gives some acceptable approximation
of real arithmetic, such optimizations are relatively harmless.
After all if you are happy with wrong results, then I suppose
getting different wrong results faster is not unacceptable.
(wrong results here = results whose accuracy is unknown).

But as above, for serious fpt programming, a compiler that
performs non-meaning preserving transformations (e.g. assuming
that fpt addition is commutative, or even worse associative),
is a menace.



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