Polyhedron 2005 Benchmarks
Dominique Dhumieres
dominiq@lps.ens.fr
Fri Nov 18 12:57:00 GMT 2005
Paul,
your results look like:
g95 gfc ifc
ac 43.44 33.45 22.83
aermod 115.12 105.47 108.72
air 66.91 49.94 48.30
capacitor 270.45 245.17 266.55
channel 119.58 65.69 89.81
doduc 106.78 88.73 92.39
fatigue 83.26 29.03 22.40
gas_dyn 79.33 45.58 63.35
induct 153.96 71.66 96.89
linpk 129.91 114.28 124.71
mdbx 64.94 64.17 65.61
nf 193.69 201.18 130.06
protein 167.25 123.41 119.37
rnflow 136.43 120.68 122.26
test_fpu 101.43 87.77 87.34
tfft 29.30 28.14 28.27
mine are:
1.8Ghz G5, OSX 10.3.9 2.0Ghz AMD64, Linux
512k L2 cache 1024k L2 cache
g95 gfc xlf-3 xlf-5 g95 gfc pgf ifc
ac 40.2 42.9 32.4 17.8* 24.1 18.0 29.5 21.2
aermod 115.7 107.8 76.2 76.6 65.0 err. 57.3* 71.6
air 49.0 48.4 42.6 25.3 25.6 21.1 19.0 17.1*
capacita 206.5 193.6 174.1 171.9 127.8 112.5 76.6* 132.2
channel 65.6 16.5* 40.4 42.0 30.9 17.6 20.6 20.4
doduc 76.1 72.5 73.9 58.7 65.4 52.5 45.3* 57.3
fatigue 86.1 34.5 18.4 11.3'* 44.6 25.5 13.1 20.1
gas_dyn 66.8 55.7 39.9 30.4 27.3 21.0 10.7* 11.3
induct 140.6 295.2 50.8 42.8'* 83.7 225.6 47.9 95.5
kepler 88.9 95.0 46.9 41.5 106.4 93.9 28.8* 34.2
linpk 35.8 35.2 34.7 34.2* 43.9 39.5 41.4 39.5
mdbx 34.9 33.7 29.2 28.2 32.4 30.0 25.9* 27.5
nf 103.5 116.9 40.3 39.5 60.1 68.7 39.4* 42.5
protein 107.5 69.9 82.4 85.1 93.3 66.3* 79.4 72.8
rnflow 85.3 81.7 63.5 63.1 57.5 61.4 51.4 48.4*
test_fpu 52.6 49.1 32.5 40.0 34.1 28.8 26.2 24.0*
tfft 17.2 17.9 16.4 16.2 10.0* 10.2 10.6 10.1
* fastest timing.
' module free_input compiled with -O3 and the remaining with -O5
It seems that your AMD is slower than mine and have a smaller L2 cache.
If so, it confirms that some of the Polyhedron tests are sensitive to the
L2 cache size (I have proof of that for tfft).
I also confirm that mod() is slow in g95 and gfc (g77 as well), that there
is a large benefit to inline dot_product (at least for small vectors).
In addition replacing 3 dot_products by a matmul of a 3x3 matrix times a
length 3 vector gives catastrophic results (with all compilers) and
g95 and gfc are unable to reorder loops such as
do i = 1, ni
do j = 1, nj
a(i,j) = b(i,j)
end do
end do
Such constructs are used almost everywhere in air.f90 (on purpose to test
compilers or because of a C programmer?). A manual reordering of the most
obvious loops gives:
air.v1 31.4 25.9 24.9 25.3 24.1 19.2 17.3 17.2*
(almost a factor 2 for gfc on G5 -> cache effect again?)
Dominique
PS1. The latest available build of x86_64-unknown-linux-gn seems to be
2005/10/24. Is there an other source than quatramaran.ens.fr? If no, where
can I find instructions on how to build it from sources as a non-root user?
PS2. In my test the flags are:
-O3 -ffast-math -funroll-loops
for g95 and gfortran (gfc) (plus -i4 for tfft with g95 on AMD),
-O3 or -O5 for xlf (plus -qsave for test_fpu.f90:
on OSX 10.3.9 stacksize has a 64Mbytes hard limid, if someone knows
how to change it, I'll be glad to know!-),
-Bstatic -V -fastsse -Munroll=n:4 -Mipa=fast,inline -tp k8-64
for the Portland Group fortran (pgf), and
-O3 -xW -ipo -static -V
for the Intel fortran (ifc, no -ipo for aermod).
The compiler versions are:
on G5
G95 Fortran 95 version 4.0.2 (g95!) Nov 14 2005 (powerpc-apple-darwin7.9.0)
GNU F95 version 4.1.0 20051112 (experimental) (powerpc-apple-darwin7)
xlf beta
on AMD
G95 Fortran 95 version 4.0.1 (g95!) Nov 11 2005 (x86_64-unknown-linux-gnu)
GNU F95 version 4.1.0 20051024 (experimental) (x86_64-unknown-linux-gnu)
Intel(R) Fortran Compiler for 32-bit applications, Version 8.1 Build 20041019Z Package ID: l_fc_pu_8.1.021
PGF90/x86 Linux/x86-64 6.0-2
I recently realized that some bus errors I got with xlf (air, linpk, nf,
rnflow, and test_fpu) and ifc (capacita and nf) were due toa too small
stack size. This was solved with
limit stacksize unlimited (csh)
ulimit -s unlimited (sh)
More information about the Fortran
mailing list