GCC beaten by ICC in stupid trig test!

[Scott Robert Ladd]

Robert Dewar wrote:
> 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.
> 
> 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.

I strongly concur with everything Robert said here. People have a wide 
range of requirements for floating point code; what may work well for a 
game is not going to work well for a details. Sometimes, you need high 
accuracy; sometimes you need reproducible results on many platforms; 
sometimes, you need fast numbers the have low precision requirements. A 
quality compiler must make clear how options affect these parameters, 
and allow precise control of its behavior.

I'm working on an advanced accuracy benchmark for C, C++, and Fortran 
95; if anyone has suggestions, please feel free to e-mail me privately.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing