Fortran computes cosine 300 times faster than C (on Sun3)

[Guy Harris]

>A smart C compiler could come close but you would have to flip a few
>switches.

And somehow convince it that "cos" is a pure function, e.g. with the
"__builtin_cos" mechanism described in other postings.

>	From what I've heard, FORTRAN compilers have been ludicrously
>optimizing since the dawn of time (~1950?)

~1954, as I remember, but I don't know that the original (Backus?)
FORTRAN compiler would do the level of optimizing that you describe
(especially in non-trivial cases).

>I would much rather use C but I can't remember any huge interest in
>optimizing C code to death.

Well, there's:

	GCC;

	the MIPS C compiler;

	the SunOS 4.0 C compiler, at least on 68K and SPARC;

	and a number of other vendors' and third-party compilers (the
	ones listed are the ones I *know* do "aggressive" optimization -
	I'm sure there are others; I think VMS C, Apollo C, and HP
	Precision Architecture C do, and there are probably more that do
	as well);

so I see a fair bit of interest in it, at least on the compiler-writers
side; presumably, they're not all doing it just for their health, and
there's demand for aggressively-optimizing C compilers.

>Just think what it would do to your timing loops 
>  for (i=0; i<6 jillion; i++) {}
>optimized into nothing.

I'd rather think of the good things it can do for the 99.9999999% of
code I deal with that's *not* just timing loops (e.g., doing
interprocedural register allocation - something you can't do in vanilla
C without cheating and "knowing" how the compiler allocates registers;
such "knowledge" can become invalid with the next release of the
compiler, and may be invalid on compilers for other architectures or
even on other compilers for the same architecture - and even if C were
modified to allow it, I'm not sure I'd trust myself not to screw up and
forget to change one routine when its predecessor or successor on the
call chain is changed).