Re: GCC Benchmarks (coybench), AMD64 and i686, 14 August 2004

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 >                  3.2.3  3.3.3  3.4.2  3.5.0  icc 8
 >                  -----  -----  -----  -----  -----
 >      alma time:   39.5   39.6   39.0   22.3   13.3
 >      arco time:   27.8   26.9   25.1   27.3   27.7
 >       evo time:   43.1   42.9   42.4   42.1   30.1
 >       fft time:   27.4   27.4   27.0   27.3   30.2
 >      huff time:   23.1   23.6   18.0   13.1   16.3
 >       lin time:   19.1   19.1   18.9   19.5   19.1
 >      mat1 time:    7.4    7.5    7.5    7.5    7.4
 >      mole time:   31.6   30.5   30.9   31.3    5.1
 >      tree time:   30.9   32.3   28.3   25.6   28.8
 >     ----------   -----  -----  -----  -----  -----
 >     total time:  249.9  249.7  237.1  215.8  178.0
 > 
 > Since we're interested in generated code speed, all compiles were performed with the option set used by typical users:
 > 
 >   -O3 -ffast-math -march=pentium4

Hi Scott,

Does your glibc contain the fixes posted here?
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01720.html
It seems like Jakub predicts these fixes will be in glibc 2.3.4 which
is the version you listed you have, but I wanted to be sure.
Otherwise, it's not a fair test if the well known glibc trig "inlines"
are killing gcc vs icc.

If you have the fixes, I'm curious to know if Jakub got all the
builtin cases gcc handles.  You can easily tell by looking at the -E
output for alma with 3.5.0 and checking for asm statements.  (There
shouldn't be any because I think all the trig funcs alma used were
done.)  Conversely, if -D__NO_MATH_INLINES improves alma, then he
missed a few.

I'd also like to know how icc works around this issue.  Does it
provide it's own C library?  Does it use glibc but disable the inlines
somehow?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu