Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Scott Robert Ladd]

Hello, all,

I've posted a set of benchmarks comparing the performance of code generated
by gcc 3.0.4 against that generated by Intel C++ 6.0 for Linux:

http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html

Please read the entire article before drawing any conclusions.

Scott Robert Ladd
Coyote Gulch Productions,  http://www.coyotegulch.com
No ads -- just very free (and somewhat unusual) code.

Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Jan Hubicka]

> Hello, all,
> 
> I've posted a set of benchmarks comparing the performance of code generated
> by gcc 3.0.4 against that generated by Intel C++ 6.0 for Linux:
> 
> http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html

Interesting comparison..
Would you please try how does
-funroll-loops/-funroll-all-loops/-fomit-frame-pointer/-ffast-math change the
picture?  Also you may grab the 3.1.0 prerelease available already and use
it for benchmarking.

Honza
> 
> Please read the entire article before drawing any conclusions.
> 
> Scott Robert Ladd
> Coyote Gulch Productions,  http://www.coyotegulch.com
> No ads -- just very free (and somewhat unusual) code.

RE: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Scott Robert Ladd]

HI,

I asked RedHat's Richard Henderson about which options I should use for
getting the fastest code from gcc; he only suggested -O2. In fact, he wasn't
real hot on -O3 (which I used) because he thought it might slow code down
through bloat.

I am looking into this further; I hope to have an updated comparison,
including reader comments, over the weekend.

..Scott

> -----Original Message-----
> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org]On Behalf Of
> Jan Hubicka
> Sent: Thursday, May 09, 2002 09:04
> To: Scott Robert Ladd
> Cc: Gcc@Gnu. Org
> Subject: Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0
>
>
> > Hello, all,
> >
> > I've posted a set of benchmarks comparing the performance of
> code generated
> > by gcc 3.0.4 against that generated by Intel C++ 6.0 for Linux:
> >
> > http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html
>
> Interesting comparison..
> Would you please try how does
> -funroll-loops/-funroll-all-loops/-fomit-frame-pointer/-ffast-math
>  change the
> picture?  Also you may grab the 3.1.0 prerelease available already and use
> it for benchmarking.
>
> Honza
> >
> > Please read the entire article before drawing any conclusions.
> >
> > Scott Robert Ladd
> > Coyote Gulch Productions,  http://www.coyotegulch.com
> > No ads -- just very free (and somewhat unusual) code.
>

Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Jan Hubicka]

> HI,
> 
> I asked RedHat's Richard Henderson about which options I should use for
> getting the fastest code from gcc; he only suggested -O2. In fact, he wasn't
> real hot on -O3 (which I used) because he thought it might slow code down
> through bloat.

It depends on the nature of code you do use.
Using -O2 results in overall best resuts, as it does not trade too much of code
size for speed, but in case of code with small internal loops unrolling helps,
similary for code with many function calls inlining helps.
Your code generally seems to stress abstraction penalty or contain small loops.

You may take a look at http://www.suse.de/~aj/SPEC for study of effect of
various switches on gcc 3.0.0 and SPEC benchmark.

Note that comparing gcc to Intel C++, Intel C++ seems to win for numeric code,
while for integer code, the results are usually much more balanced.

Honza
> 
> I am looking into this further; I hope to have an updated comparison,
> including reader comments, over the weekend.
> 
> ..Scott
> 
> > -----Original Message-----
> > From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org]On Behalf Of
> > Jan Hubicka
> > Sent: Thursday, May 09, 2002 09:04
> > To: Scott Robert Ladd
> > Cc: Gcc@Gnu. Org
> > Subject: Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0
> >
> >
> > > Hello, all,
> > >
> > > I've posted a set of benchmarks comparing the performance of
> > code generated
> > > by gcc 3.0.4 against that generated by Intel C++ 6.0 for Linux:
> > >
> > > http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html
> >
> > Interesting comparison..
> > Would you please try how does
> > -funroll-loops/-funroll-all-loops/-fomit-frame-pointer/-ffast-math
> >  change the
> > picture?  Also you may grab the 3.1.0 prerelease available already and use
> > it for benchmarking.
> >
> > Honza
> > >
> > > Please read the entire article before drawing any conclusions.
> > >
> > > Scott Robert Ladd
> > > Coyote Gulch Productions,  http://www.coyotegulch.com
> > > No ads -- just very free (and somewhat unusual) code.
> >

RE: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Scott Robert Ladd]

Jan Hubicka said:
> You may take a look at http://www.suse.de/~aj/SPEC for study of effect of
> various switches on gcc 3.0.0 and SPEC benchmark.

Thanks for the point; I'd missed that page.

> Note that comparing gcc to Intel C++, Intel C++ seems to win for
> numeric code,
> while for integer code, the results are usually much more balanced.

Very true. I'm performing an experiment with many different gcc options; it
looks like I might want to write an article on how to optimize code with
gcc. ;)

Scott Robert Ladd
Coyote Gulch Productions,  http://www.coyotegulch.com
No ads -- just very free (and somewhat unusual) code.

Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Jan Hubicka]

> Jan Hubicka said:
> > You may take a look at http://www.suse.de/~aj/SPEC for study of effect of
> > various switches on gcc 3.0.0 and SPEC benchmark.
> 
> Thanks for the point; I'd missed that page.
> 
> > Note that comparing gcc to Intel C++, Intel C++ seems to win for
> > numeric code,
> > while for integer code, the results are usually much more balanced.
> 
> Very true. I'm performing an experiment with many different gcc options; it
> looks like I might want to write an article on how to optimize code with
> gcc. ;)

Yes, generally choosing options depends on code you have.
I believe -O2 is good for compiling standard programs and that it is better
than the default setting of Intel compiler, but for benchmark it is not
easy to tunne the perofmrance.
For instance when you compile KDE with -O3 or -funroll-loops, you will
definitely loose, but when you compile whetstones, you win.
Even large scale benchmarks, like SPEC2000, are much smaller than the average
applications run today, so the results needs to be interpreted with this
in the mind.

Honza
> 
> Scott Robert Ladd
> Coyote Gulch Productions,  http://www.coyotegulch.com
> No ads -- just very free (and somewhat unusual) code.

Updated: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Scott Robert Ladd]

Hi, all!

After some morning tests and comparisons, I've updated the comparison of
Intel C++ 6.0 and gcc 3.0.4 with new compile-time options for the later.
What produced the fastest code for my tests was:

gcc  -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -march=i686

I also tried several other options (listed in the updated article) which did
not seem to improve gc's performance.

http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html

With the new options, gcc performs much better on some tests.

..Scott

Re: Updated: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Neil Booth]

Scott Robert Ladd wrote:-

> After some morning tests and comparisons, I've updated the comparison of
> Intel C++ 6.0 and gcc 3.0.4 with new compile-time options for the later.
> What produced the fastest code for my tests was:
> 
> gcc  -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -march=i686
> 
> I also tried several other options (listed in the updated article) which did
> not seem to improve gc's performance.
> 
> http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html
> 
> With the new options, gcc performs much better on some tests.

You should update the commentary as well as the numbers.

Neil.

Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Jack Lloyd]

On Thu, 9 May 2002, Jan Hubicka wrote:

> Note that comparing gcc to Intel C++, Intel C++ seems to win for numeric code,
> while for integer code, the results are usually much more balanced.

I just yesterday got a copy of Intel C++ 6.0 and compiled benchmarks of a
bunch of integer heavy code (virtually no fp used). I found GCC 3.0.4 to be
significantly faster.

GCC: -O3 -fomit-frame-pointer -fstrict-aliasing -march=athlon
ICC: -O2 -tp i686 -ip

YMMV and all that. -Jack

# of untested cases 22 for alpha g++ only 9 for intel

[bemis]

Hello,
Can I help out with the alpha tests?
alpha:
                === g++ Summary ===

# of expected passes            7162
# of unexpected failures        1
# of expected failures          88
# of untested testcases         22
# of unsupported tests          4
/mnt/u9/toolchain/buildsys/build/alpha9/basic/native/gcc-3_1-branch/gcc/testsuit
e/../g++ version 3.1 20020508 (prerelease)

intel only has 9 untested case here:
                === g++ Summary ===

# of expected passes            7184
# of expected failures          88
# of untested testcases         9
# of unsupported tests          3
/home/buildsys/build/intel1/basic/native/gcc-3_1-branch/gcc/testsuite/../g++ ver
sion 3.1 20020508 (prerelease)

alpha stopped testing g++ because of the following error:
FAIL: g++.dg/template/recurse.C (test for excess errors)
Excess errors:
/mnt/u9/toolchain/buildsys/source/gcc-3_1-branch/gcc/testsuite/g++.dg/template/r
Executing on host: /mnt/u9/toolchain/buildsys/build/alpha9/basic/native/gcc-3_1-
branch/gcc/testsuite/../g++ -B/mnt/u9/toolchain/buildsys/build/alpha9/basic/nati
ve/gcc-3_1-branch/gcc/testsuite/../ /mnt/u9/toolchain/buildsys/source/gcc-3_1-br
anch/gcc/testsuite/g++.dg/template/spec1.C  -nostdinc++ -I/mnt/u9/toolchain/buil
dsys/build/alpha9/basic/native/gcc-3_1-branch/alphaev56-unknown-linux-gnu/libstd
c++-v3/include/alphaev56-unknown-linux-gnu -I/mnt/u9/toolchain/buildsys/build/al
pha9/basic/native/gcc-3_1-branch/alphaev56-unknown-linux-gnu/libstdc++-v3/includ
e -I/mnt/u9/toolchain/buildsys/source/gcc-3_1-branch/libstdc++-v3/libsupc++ -I/m
nt/u9/toolchain/buildsys/source/gcc-3_1-branch/libstdc++-v3/libio -I/mnt/u9/tool
chain/buildsys/source/gcc-3_1-branch/libstdc++-v3/include/backward -I/mnt/u9/too
lchain/buildsys/source/gcc-3_1-branch/libstdc++-v3/testsuite -fmessage-length=0
  -ansi -pedantic-errors -Wno-long-long  -S  -o spec1.s    (timeout = 300)
/mnt/u9/toolchain/buildsys/source/gcc-3_1-branch/gcc/testsuite/g++.dg/template/s
pec1.C:21: template-id `f<>' for `void A<int>::f(int)' does not match any templa
te declaration
compiler exited with status 1
output is:
/mnt/u9/toolchain/buildsys/source/gcc-3_1-branch/gcc/testsuite/g++.dg/template/s
pec1.C:21: template-id `f<>' for `void A<int>::f(int)' does not match any templa
te declaration

Compilation Error on alphas

[bemis]

>
> alpha stopped testing g++ because of the following error:
> FAIL: g++.dg/template/recurse.C (test for excess errors)
> Excess errors:
> /mnt/u9/toolchain/buildsys/source/gcc-3_1-branch/gcc/testsuite/g++.dg/template/r
> Executing on host: /mnt/u9/toolchain/buildsys/build/alpha9/basic/native/gcc-3_1-
> branch/gcc/testsuite/../g++ -B/mnt/u9/toolchain/buildsys/build/alpha9/basic/nati
> ve/gcc-3_1-branch/gcc/testsuite/../ /mnt/u9/toolchain/buildsys/source/gcc-3_1-br
> anch/gcc/testsuite/g++.dg/template/spec1.C  -nostdinc++ -I/mnt/u9/toolchain/buil
> dsys/build/alpha9/basic/native/gcc-3_1-branch/alphaev56-unknown-linux-gnu/libstd
> c++-v3/include/alphaev56-unknown-linux-gnu -I/mnt/u9/toolchain/buildsys/build/al
> pha9/basic/native/gcc-3_1-branch/alphaev56-unknown-linux-gnu/libstdc++-v3/includ
> e -I/mnt/u9/toolchain/buildsys/source/gcc-3_1-branch/libstdc++-v3/libsupc++ -I/m
> nt/u9/toolchain/buildsys/source/gcc-3_1-branch/libstdc++-v3/libio -I/mnt/u9/tool
> chain/buildsys/source/gcc-3_1-branch/libstdc++-v3/include/backward -I/mnt/u9/too
> lchain/buildsys/source/gcc-3_1-branch/libstdc++-v3/testsuite -fmessage-length=0
>   -ansi -pedantic-errors -Wno-long-long  -S  -o spec1.s    (timeout = 300)
> /mnt/u9/toolchain/buildsys/source/gcc-3_1-branch/gcc/testsuite/g++.dg/template/s
> pec1.C:21: template-id `f<>' for `void A<int>::f(int)' does not match any templa
> te declaration
> compiler exited with status 1
> output is:
> /mnt/u9/toolchain/buildsys/source/gcc-3_1-branch/gcc/testsuite/g++.dg/template/s
> pec1.C:21: template-id `f<>' for `void A<int>::f(int)' does not match any templa
> te declaration

matt

Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Tim Prince]

On Thursday 09 May 2002 07:33, Jack Lloyd wrote:
> On Thu, 9 May 2002, Jan Hubicka wrote:
> > Note that comparing gcc to Intel C++, Intel C++ seems to win for numeric
> > code, while for integer code, the results are usually much more balanced.
>
> I just yesterday got a copy of Intel C++ 6.0 and compiled benchmarks of a
> bunch of integer heavy code (virtually no fp used). I found GCC 3.0.4 to be
> significantly faster.
>
> GCC: -O3 -fomit-frame-pointer -fstrict-aliasing -march=athlon
> ICC: -O2 -tp i686 -ip
>
> YMMV and all that. -Jack
icc's equivalent to -fstrict-aliasing is -ansi.  It's not a default. AFAIK, 
the -tp options most likely to work well on Athlon are -tpp6 (P-II/III) or 
-tpp7 (P4), and you should be using -xi (P-II) or -xK (P-III/Palomino) 
options, unless you want the default 586 code.  The -axK option will generate 
both a 586 and a P-III code path, but the Athlon will take the 586.  Triumph 
of Intel marketing.
-- 
Tim Prince

RE: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Scott Robert Ladd]

> I just yesterday got a copy of Intel C++ 6.0 and compiled benchmarks of a
> bunch of integer heavy code (virtually no fp used). I found GCC
> 3.0.4 to be
> significantly faster.
>
> GCC: -O3 -fomit-frame-pointer -fstrict-aliasing -march=athlon
> ICC: -O2 -tp i686 -ip
>
> YMMV and all that. -Jack

You should try these options for icc:

-O3 -axK -ip

Using -O2 and without -axK, you're not optimizing to icc's full ability, at
least for Pentium-III and IV processors. Of course, you're running on an
Athlon, so your mileage may most certainly vary.

..Scott

Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[law]

In message <Pine.LNX.4.33L2.0205091025540.15140-100000@fomalhaut.galaxy.acm.jhu
.edu>, Jack Lloyd writes:
 > On Thu, 9 May 2002, Jan Hubicka wrote:
 > 
 > > Note that comparing gcc to Intel C++, Intel C++ seems to win for numeric c
 > ode,
 > > while for integer code, the results are usually much more balanced.
 > 
 > I just yesterday got a copy of Intel C++ 6.0 and compiled benchmarks of a
 > bunch of integer heavy code (virtually no fp used). I found GCC 3.0.4 to be
 > significantly faster.
Can you post the results or a pointer to the results?

jeff

Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Jack Lloyd]

On Thu, 9 May 2002 law@redhat.com wrote:

> In message <Pine.LNX.4.33L2.0205091025540.15140-100000@fomalhaut.galaxy.acm.jhu
> .edu>, Jack Lloyd writes:
>  > On Thu, 9 May 2002, Jan Hubicka wrote:
>  >
>  > > Note that comparing gcc to Intel C++, Intel C++ seems to win for numeric c
>  > ode,
>  > > while for integer code, the results are usually much more balanced.
>  >
>  > I just yesterday got a copy of Intel C++ 6.0 and compiled benchmarks of a
>  > bunch of integer heavy code (virtually no fp used). I found GCC 3.0.4 to be
>  > significantly faster.
>
> Can you post the results or a pointer to the results?
>
> jeff
>

http://www.randombit.net/misc/x86_comp.php

-Jack

Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Tim Prince]

On Thursday 09 May 2002 06:03, Jan Hubicka wrote:
> > Hello, all,
> >
> > I've posted a set of benchmarks comparing the performance of code
> > generated by gcc 3.0.4 against that generated by Intel C++ 6.0 for Linux:
> >
> > http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html
>
> Interesting comparison..
> Would you please try how does
> -funroll-loops/-funroll-all-loops/-fomit-frame-pointer/-ffast-math change
> the picture?  Also you may grab the 3.1.0 prerelease available already and
> use it for benchmarking.
>
> Honza
>
If you have any float code, you should try the sse options in gcc-3.1.  
They often out-perform the Intel compiler, in those cases where the Intel 
compiler doesn't vectorize.

-- 
Tim Prince

Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Tim Prince]

On Thursday 09 May 2002 06:03, Jan Hubicka wrote:
> > Hello, all,
> >
> > I've posted a set of benchmarks comparing the performance of code
> > generated by gcc 3.0.4 against that generated by Intel C++ 6.0 for Linux:
> >
> > http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html
>
> Interesting comparison..
> Would you please try how does
> -funroll-loops/-funroll-all-loops/-fomit-frame-pointer/-ffast-math change
> the picture?  Also you may grab the 3.1.0 prerelease available already and
> use it for benchmarking.
>
> Honza
>
If you have any float code, you should try the sse options in gcc-3.1.  
They often out-perform the Intel compiler, in those cases where the Intel 
compiler doesn't vectorize.

-- 
Tim Prince

Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Erik Schnetter]

Tim Prince <tprince at computer dot org> wrote:

> icc's equivalent to -fstrict-aliasing is -ansi.  It's not a default.

I couldn't find anything about aliasing in the description of "-ansi".  
However, icc does have a "-falias" option (which is also not the default).  
The description of "-falias" is unfortunately unusable.

-erik

-- 
Erik Schnetter <schnetter@uni-tuebingen.de>
Web: http://www.tat.physik.uni-tuebingen.de/~schnette/

Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Tim Prince]

On Thursday 09 May 2002 08:42, Erik Schnetter wrote:
> Tim Prince <tprince at computer dot org> wrote:
> > icc's equivalent to -fstrict-aliasing is -ansi.  It's not a default.
>
> I couldn't find anything about aliasing in the description of "-ansi".
> However, icc does have a "-falias" option (which is also not the default).
> The description of "-falias" is unfortunately unusable.
>
> -erik
I'll look into this later.
-- 
Tim Prince

Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Daniel Berlin]

On Thu, 9 May 2002, Erik Schnetter wrote:

> Tim Prince <tprince at computer dot org> wrote:
> 
> > icc's equivalent to -fstrict-aliasing is -ansi.  It's not a default.
> 
> I couldn't find anything about aliasing in the description of "-ansi".  

It does what he says, however, i can prove it through option dumps (it 
turns on P2OPT_disam_assume_ansi_c)
> However, icc does have a "-falias" option (which is also not the default).  
> The description of "-falias" is unfortunately unusable.

You mean -fno-alias and -fno-fnalias, i thinks.

If you want to see the aliasing/intermediate code dumps for intel's 
compiler, so you can watch what it does at each stage, "-mIPOPT_trace=-1 
-mP1OPT_il0_trace=-1 -mP2OPT_il0_list_source_lines=-1 -mP2OPT_il0_dump=0 
-mIPOPT_opt_trace=-1"  will suffice.

If you want the debug options to print the mod-ref sets and whatnot, let 
me know.


> 
> -erik
> 
> 

Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Tim Prince]

On Thursday 09 May 2002 09:01, Daniel Berlin wrote:
> On Thu, 9 May 2002, Erik Schnetter wrote:
> > Tim Prince <tprince at computer dot org> wrote:
> > > icc's equivalent to -fstrict-aliasing is -ansi.  It's not a default.
> >
> > I couldn't find anything about aliasing in the description of "-ansi".
>
> It does what he says, however, i can prove it through option dumps (it
> turns on P2OPT_disam_assume_ansi_c)
>
> > However, icc does have a "-falias" option (which is also not the
> > default). The description of "-falias" is unfortunately unusable.
>
> You mean -fno-alias and -fno-fnalias, i thinks.
>
> If you want to see the aliasing/intermediate code dumps for intel's
> compiler, so you can watch what it does at each stage, "-mIPOPT_trace=-1
> -mP1OPT_il0_trace=-1 -mP2OPT_il0_list_source_lines=-1 -mP2OPT_il0_dump=0
> -mIPOPT_opt_trace=-1"  will suffice.
>
> If you want the debug options to print the mod-ref sets and whatnot, let
> me know.
>
> > -erik
Thanks for this information.  I was intending to test whether -ansi affected 
vectorization when I got a chance. Meanwhile, I've noticed that the latest 
Windows ICL documentation says -Qansi is on by default, which I disbelieve, 
since the defaults are often compatible with Microsoft's, and because even 
the Fortran 6.0 assumes argument aliasing, contrary to Fortran standards of 
36 years standing. Also, it would be mighty strange to have it on by default 
in Windows, which is notorious for dirty C, and off for linux, where the gcc 
struggles should have raised awareness of the issues. They agreed to correct 
the Fortran default for 7.0, but that shouldn't have a direct bearing on C.  
I'll be filing a documentation problem report with Intel, but I'd like to 
have as many facts at hand as possible.  The description of -ansi is 
certainly oblique.  It assumes [the program is in] conformance with ISO C89 
[the main consequence being that typed aliasing analysis can be employed, as 
with gcc -fstrict-aliasing].
-- 
Tim Prince

Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[kelley.r.cook]

>I've posted a set of benchmarks comparing the performance of code
generated
>by gcc 3.0.4 against that generated by Intel C++ 6.0 for Linux:
>
>http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html

From your web site:
>I've updated the benchmark tables, showing the performance gain by using
>these options: -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math
>-march=i686. I also tried several other options suggested by various
e-mail
>and mailing list correspondents, including -malign-double,
>-fprefetch-loop-arrays, and -fstrict-aliasing; none of those improved
>performance on the benchmark code.

-malign-double used to matter in the old egcs, but it breaks ABI and isn't
really all that useful anymore anyway.  Jeff Law once called it evil:
http://gcc.gnu.org/ml/gcc-bugs/2000-08/msg00586.html

-fstrict-aliasing *does* matter, but since it is enabled by default since
the 3.0 release, it obviously wouldn't change your benchmark times.

-fprefetch-loop-arrays also matters on code that can take advantage of it.
However, it is a new 3.1 option and only will come into play on
architectures that support prefetch, in the x86 world, this requires chips
with SSE or 3DNow support.  Once you get the 3.1 try it along with
-march=pentium3 (since that is actually what you have).

For grins also add in a -fpmath=sse which is also a new for 3.1 command.
Their is no auto-vectorization support yet, but even scalar FP code
performs
much (10-25%) better than the x87 default.

Kelley Cook

Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[law]

 In message <OF6E1D2590.BC939BCE-ON85256BB4.005A2414@mail.gm.com>, 
kelley.r.cook
@gm.com writes:
 > -malign-double used to matter in the old egcs, but it breaks ABI and isn't
 > really all that useful anymore anyway.  Jeff Law once called it evil:
 > http://gcc.gnu.org/ml/gcc-bugs/2000-08/msg00586.html
Correct.  Extremely evil as it changes the underlying ABI by changing
the layout & size of structures.

jeff

RE: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0

[Robert Dewar]

<<I asked RedHat's Richard Henderson about which options I should use for
getting the fastest code from gcc; he only suggested -O2. In fact, he wasn't
real hot on -O3 (which I used) because he thought it might slow code down
through bloat.
>>

-O3 is often slower than -O2 in our experience particularly in Ada, where
it is routine to properly specify explicit inlining for appropriate subprograms