Polyhedron speed comparison (on AMD64)

[Tobias Burnus]

Hi,

Paul Thomas wrote:
>> Thus we are not yet back at our original speed, maybe one should find
>> the reason for the extra 2s step at Nov 13/14.  
> Nothing stands out in fortran or libgfortran, does it?

According to
http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt
the performance regressions occur for ac between Nov 13 and Nov 14 (~31
to ~33.5s) -> 8% slower and for protein between Nov 14 (~70s) and Nov 15
(~73s) -> 4% slower. Thanks for Uros for pointing out the latter.

I didn't do performance a detailed regression tests, but with my nightly
builds
using "gfortran -march=opteron -ffast-math -funroll-loops
-ftree-vectorize -msse3 -O3"

First result: I cannot find the ac regression ?!?
for protein, it must be between r118802 and r118918 (4% slower, same as
Richi's results.)

2006-11-11-r118703
ac:
22.20user 0.00system 0:22.21elapsed
22.10user 0.00system 0:22.10elapsed
22.12user 0.00system 0:22.12elapsed
protein:
51.94user 12.79system 1:04.73elapsed
51.51user 12.64system 1:04.16elapsed
52.19user 12.25system 1:04.45elapsed

2006-11-13-r118746
ac:
23.24user 0.00system 0:23.24elapsed
22.19user 0.01system 0:22.20elapsed
22.19user 0.00system 0:22.20elapsed
protein:
51.65user 12.44system 1:04.09elapsed
51.26user 12.49system 1:03.75elapsed
51.97user 12.02system 1:03.99elapsed

2006-11-14-r118802
ac:
22.84user 0.00system 0:22.84elapsed
22.43user 0.00system 0:22.44elapsed
22.43user 0.00system 0:22.44elapsed
protein:
51.57user 12.31system 1:03.88elapsed
51.68user 12.50system 1:04.18elapsed
51.71user 12.25system 1:03.96elapsed

2006-11-17-r118918
ac:
23.24user 0.00system 0:23.25elapsed
22.23user 0.00system 0:22.23elapsed
22.09user 0.00system 0:22.09elapsed
protein:
53.79user 12.48system 1:06.28elapsed
53.80user 12.38system 1:06.19elapsed
53.83user 12.31system 1:06.14elapsed


>> A reduce C test case: gcc 0m7.2s and icc 0m2.4s. I filled PR30032.
>> If anyone has an idea what gfortran or GCC should do better ...
The reason why the C test is slower is that I was using Variable-Length
Arrays (VLA) instead of #define, which icc automatically transforms into
normal arrays as Andrew immediately suspected. Why the Fortran test case
is slower, I don't know, and whether the slowness of the Fortran example
has the same reason as Polyhedron's gas_dyn.f90 is the next question. (I
think they reasons for the slowness of the Fortran example and gas_dyn
are the same.)
Tim thinks that there is a vectorizing problem, if I understood him
correctly.
For the Fortran test case, ifort claims:
gastest.f90(8) : (col. 3) remark: LOOP WAS VECTORIZED.
gastest.f90(9) : (col. 3) remark: LOOP WAS VECTORIZED.
gastest.f90(23) : (col. 7) remark: LOOP WAS VECTORIZED.
and gfortran:
gastest.f90:8: note: LOOP VECTORIZED.
gastest.f90:9: note: LOOP VECTORIZED.
gastest.f90:1: note: vectorized 2 loops in function.

>> (1) linpk FAILED    1 fails and    4 passes
>>     Value= 25.114499300     Target= 23.100000000     Tolerance=
>> 2.0000000000  
> Is this new? I do not recall seeing it.
This is a side effect of using -ffast-math. Without I get the same
results as with the other compilers:
25.0952975 which is just within the tolerance given.
 
> Fixing gas_dyn and fatigue would close the gap [to ifort].
See email by Tim (thanks!):
- (vector) sincos, filled as PR30038
- too many (de)allocates
Some one willing to investigate the latter?

Tobias