Polyhedron benchmark results on AMD64

[Dominique Dhumieres]

> I've been doing (for professional use) a run of the Polyhedron benchmark
> of the Fortran 95 compilers I have at hand on one of my x86_64-linux
> machines (this is: GNU, Intel, Portland, Sun and g95;

If you want to see the progress you may have a look to

http://gcc.gnu.org/ml/fortran/2005-11/msg00500.html

With my latest timings with GNU Fortran 95 (GCC) 4.3.0 20061114
on a 2Ghz AMD Opteron(tm) Processor 246 with 1024k L2 cache
I have some significant differences on a few timings.

I have fiddled with some tests, mostly induct.f90 and if you are 
interested you can download the variants from

http://www.lps.ens.fr/~dominiq/polyhedron/

(*_4*, *_8*, and *_10* are variants with different precisions, *_u*
are REAL variants intended to test the -r8 and -r10 options of g95,
sorry but I can never remember the equivalent of -r8 for gfortran
though I know where to find it == no need for pointer).

I made the induct variants when dot_product was not inlined, vm replaces 3
dot products by a matrix-vector product and is a disaster for all
compilers, v2 and v3 are hand optimizations (basically removing dot
products) and gfortran does not do better (now) on them than on the
original code.  Note that xlf -O5 gives:

induct: 42.8s, indu.v2: 25.8s, and indu.v3: 28.7s on a 1.8Ghz G5 (mono)

so my hand optimizations help xlf significantly.

If there is some interest, I can compile my most recent results in the same
way as in my 2005-11 mail (no changes for xlf, ifc, pgf that I did not 
tested again).  If you want the comparison to g95 ask for.

Steve Kargl wrote:

> I looked at gas_dyn a long time ago.  My conclusion was that
> gfortran needed to do inter-procedure optimizations to make
> any big gains.

I cannot comment on this, but I had a look to the code and did not find 
any obvious way to hand optimize the code.

Another thing I have noticed is that temporaries have a much bigger impact
on G5 under OSX (especially OS mallocs) than on AMD under Linux while the
G5 has a slight edge on raw computations, so the bad timings on OSX are
probably a good indication of a penalty due to temporaries.

If someone has ideas on how I can contibute to this direction, they are 
welcome. 

Cheers

Dominique