This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.
-----------------------------------------------------------------


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]