This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC Benchmarks (coybench), AMD64 and i686, 14 August 2004
> A B C icc
> ----- ----- ----- -----
> alma: 43.2 22.2 23.7 13.2
> arco: 27.4 27.2 27.2 20.5
> evo: 43.4 42.0 63.8 29.8
> fft: 27.7 27.5 28.4 30.4
> huff: 13.9 13.1 13.2 16.4
> lin: 20.2 19.6 19.8 19.2
> mat1: 7.7 7.5 7.4 7.4
> mole: 8.8 6.7 6.8 2.1
> tree: 26.0 25.7 25.8 28.8
> ----- ----- ----- ----- -----
> total: 218.4 191.7 216.2 167.8
>
>
> Hmmmm... I don't see where adding the -D__NO_??? options helped GCC --
> in fact, those options hindered run time severely on the evo test!
Scott - thanks very much for running these tests, it was very informative.
Based on the results I conclude these things.
1. Your current glibc *has* the patches that Jakub produced which
benefits both 3.4 and 3.5. Whereas in May, the -D__NO_* flags
made an improvement:
http://gcc.gnu.org/ml/gcc/2004-05/msg00037.html
now, clearly they don't help. This is an improved situation, I
want us to compare apples to apples when competing against ICC.
We're closer to testing the compilers fairly now.
2. In May GCC-3.4.1 beat ICC on alma, now it's the reverse. Did GCC
get worse, or did ICC get better? See:
http://gcc.gnu.org/ml/gcc/2004-05/msg00114.html
Something is fishy here.
3. The evo test didn't regress in May when inlines were off,
something else must be going on here. Again see:
http://gcc.gnu.org/ml/gcc/2004-05/msg00037.html
> Now people know why I don't specify all those #defines when I run my
> tests; I haven't seen a measurable gain in generated code speed from
> their use.
Yes you have, you just forgot. See #1.
Thanks,
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
- References:
- GCC Benchmarks (coybench), AMD64 and i686, 14 August 2004
- Re: GCC Benchmarks (coybench), AMD64 and i686, 14 August 2004
- Re: GCC Benchmarks (coybench), AMD64 and i686, 14 August 2004
- Re: GCC Benchmarks (coybench), AMD64 and i686, 14 August 2004
- Re: GCC Benchmarks (coybench), AMD64 and i686, 14 August 2004