Optimization comparison: 3.3, 3.4, mainline, tree-ssa

[Scott Robert Ladd]

Kaveh R. Ghazi wrote:
>  > Performance on the "alma" test is predicated on the speed of the
>  > sin(), cos(), and sqrt() functions. I've tried -D__NO_INLINE__,
>  > -fno-inline, and other suggestions, without finding anything that
>  > improved GCC's performance on this benchmark.
> 
> Strange.  Using last night's mainline on i686-pc-linux-gnu, when I
> supply either -D__NO_INLINE__ or -D__NO_MATH_INLINES I get a dramatic
> 30% speedup for alma.  Still not as fast as ICC, but better than it
> was.

Hmmm... very interesting. I ran mybenchmarks on both Opteron and Pentium 
4, using the following two switch sets with 3.5-tree-ssa 20040418:

-O3 -ffast-math -march=pentium4 -D__NO_MATH_INLINES
-O3 -ffast-math -march=pentium4 -D__NO_MATH_INLINES

For the Opteron, the option sets above were equivalent -- almabench ran 
in 9.3 seconds regardless of the presence of -D__NO_MATH_INLINES.

/However/, on the Pentium 4, using -D__NO_MATH_INLINES reduced 
alambench's run time from 26.1 to 7.8 seconds, a dramatic improvement 
that puts gcc-tree-ssa /ahead/ of Intel's 9.2 second run time.

Questions to be answered: Why does gcc-tree-ssa do so well /without/ 
-D__NO_MATH_INLINES on Opteron? Is the code being generated correctly 
with both compilers and switch sets?

Time to review some assembly code... ;)

> We (the gcc and glibc communities) need to stop writing the same
> optimizations in two places and the compiler is where they belong
> because ultimately it can do a better job.

Agreed. Playing the blame game is intrinsic to human endeavours, but it 
accomplishes nothing. Free software development needs fewer 
finger-pointing camps and mroe interproject cooperation.

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