This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Optimization -- praise, problem, & question
- From: Elijah P Newren <newren at math dot utah dot edu>
- To: gcc at gcc dot gnu dot org
- Date: 09 Jun 2003 15:54:37 -0600
- Subject: Optimization -- praise, problem, & question
I apologize if I have sent this to the wrong place. If I have done so,
please let me know where this information & question should be sent. I
have three items I'd like to cover--praise for a job well done, a
problem that I noticed (a regression for optimized code in gcc 3.3
relative to gcc 3.2), and a question about further optimizations.
First of all, the praise: I think all the gcc developers deserve thanks
for putting out a great product. With gcc-3.3 and only minor hand
optimizations, I can get performance as good as fortran -- and as good
as or better than the Intel Compiler (icc version 7.1) can provide! (I
even have proof from my benchmarks at the end of this email...)
To explain the regression I found, I'm going to have to explain the
simple benchmark program that I wrote (which I've made available at
http://www.math.utah.edu/~newren/simple-2d-benchmark.tar.gz). I've
written a simple benchmark test program that is suppose to mimic the
portions of my scientific codes (and/or the portions of the SAMRAI
library developed at Lawrence Livermore National Laboratory that I'm
using) that take the longest to run. Specifically, this program loops
over a 2D array (created so as to be easily used in fortran) in 3
different ways with various levels of hand optimizations. With a
compiler that optimizes perfectly, all runs should take the same amount
of time.
These three different ways are:
fortran -- loop over 2D array of points using fortran code
arithmetic -- loop over 2D array of points and compute the index
into the long 1D array to get the relevant floating
point value location
array -- first create an array of pointers that point into the
long 1D array thus giving the illusion of a 2D
array--then loop over 2D array of points normally.
There are various tests (levels of hand optimization) for each
method of looping:
Test #0 represent the most straightforward code to perform the given
task
Test #1 represents really simple hand optimizations to test #0
Test #2 and Test #3 represent more significant hand optimizations of
the previous tests
Setup for the benchmark tables below:
All timings show wall clock time
The problem run was 'benchmark 8192', thus using an 8192x8192 array
icc-7.1 means both icc and ifc from Intel's Compiler Suite version 7.1
gcc-3.x means g++ and g77 from the relevant Gnu Compiler Collection
version
Optimization flags used with icc: -O2 -unroll
Optimization flags used with gcc: -O2 -funroll-loops
Benchmarks: Dual 1400 Mhz Athlon (1600+) running Red Hat 8.0 w/ 2 GB RAM
Test Name icc-7.1 gcc-3.2 gcc-3.3
-------------------- ------- ------- -------
Fortran test #0 1.04 1.05 1.05
Arithmetic test #0 1.59 1.61 1.60
Arithmetic test #1 1.56 1.32 1.05
Arithmetic test #2 1.03 1.03 1.02
Arithmetic test #3 1.04 1.04 1.04
Array test #0 1.43 1.57 1.57
Array test #1 1.34 1.32 1.04
Array test #2 1.26 1.05 1.05
Benchmarks: Dual 600 Mhz Pentium III running Red Hat 8.0 w/ 2 GB Memory
Test Name icc-7.1 gcc-3.2 gcc-3.3
-------------------- ------- ------- -------
Fortran test #0 2.32 2.31 2.30
Arithmetic test #0 2.48 2.90 3.16 (regression in gcc-3.3)
Arithmetic test #1 2.36 2.32 2.31
Arithmetic test #2 2.33 2.30 2.32
Arithmetic test #3 2.32 2.31 2.33
Array test #0 2.34 2.96 2.59
Array test #1 2.35 2.32 2.32
Array test #2 2.33 2.29 2.29
As you'll notice, on the 600 Mhz Pentium III using arithmetic test #0,
the code took longer when compiled with gcc-3.3 than it did with
gcc-3.2. I see no reason why this should be the case. I've re-run
these several times and I consistently get a performance penalty
somewhere in the range of 5-10% for using gcc-3.3 instead of gcc-3.2 on
that one specific test.
Finally, I was wondering if future versions of gcc (hopefully planned
for release in the next year or so) might incorporate optimizations
which would allow the arithmetic and array test #0's to be as fast as
the other methods. (I believe this means storing small objects in
registers and analyzing when and how to do that--but please correct me
if I'm wrong). It appears that the Intel compiler does do this to some
extent, and in one case it even appears to do it perfectly. [This was
the main reason I was interested in the Intel Compiler in the first
place. I'd probably start using it as well as gcc except for the fact
that I learned this weekend that the code it produces on the AMD
processor is somewhat shoddy and suspect--especially at the optimization
level 1 which represents the most hand optimizing that I'm willing to
deal with in my codes].
Thank you for your time,
Elijah
--
-----------------------------------------------------------------
Elijah Newren
Internet: http://www.math.utah.edu/~newren newren@math.utah.edu
Tired of pop-up webpages when surfing the internet? Look at
http://www.math.utah.edu/~newren/noPopUps.html
for how to get rid of them without spending a penny.
-----------------------------------------------------------------