Re: polyhedron benchmark | results queries...

[Evan Cooch <cooch17 at verizon dot net>]

Thanks for your detailed reply. Some quick follow-ups embedded below:


> Just for completeness I want to mention that the SUN Fortran compiler is
> available for x86-64 Linux for no charge (commercial and noncommercial
> use). Contrary to gfortran it is of cause not free as in liberty.
> When developing a program - contrary to merely using a program, I found
> it quite useful to have multiple compilers installed. This helps
> tremendously to find programming errors. Thus g95 could also be installed.
>   
Sounds like good advice. I've been looking at the Sun Fortran compiler, 
and may in fact install it along with gfortran.

>   
> > gfortran -march=opteron -L/opt/acml3.6.0/gfortran/lib -lacml
> > -ftree-vectorize -msse3 -ffast-math -funroll-loops -O3 $n.f90 -o %n
> >     
> I think the Polyhedron tests don't need BLAS/LAPACK and thus don't need
> the ACML.

Thanks - but, then, if the PH tests don't need BLAS, then putting BLAS 
in the compilation won't hurt anything either. Since most of my work 
involves matrix cals, I usually put BLAS (and so forth) in the 
compilation reflexively.

>  With -ffast-math one should be careful as one might get wrong
> results (unsave math optimizations), cf.
>   

I've heard that - worth trying with and without.

> http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/
>
> Please ignore the entries for aermod and rnflow in the comparison as
> here the program crashes (PR 31699, 31697) with today's developer
> version of gfortran. In total gfortran 4.3 is ~25% faster than NAG f95,
>   

OK - but I still don't know why my ac times are so much longer (2-3 
times) than anything I've seen - more or less same story for aermod. 
This, to me, is extremely puzzling. On your recently posted benchmarks, 
your ac times are much faster than mine - but other tests not so 
radically different.

> > ~50% faster than g95 (GCC 4.1.x backend, compiler crashes with
> >     
Most of my colleagues have suggested that there is no compelling reason 
for anyone to use g95 any more, so I'm wondering if it is worth even 
using it in a comparison.

>   
> > Ran the quick set (instead of standard - but results generally are
> > pretty consistent between the two), and am puzzled by whey some of the
> > tests yield results which are invariably slower (sometimes quite a bit
> > - e.g., the ac test) than other posted benchmarks, despite having been
> > generated on 'fairly similar machines'. Although the machine has 2
> > processors (4 cores), only one was used for running the benchmarks.
> >     
> There were a couple of middle/backend and frontend optimizations in
> gfortran 4.2 and gfortran 4.3. For what happend last year, see
>   
> http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-2-0.html
> (the points where the number drop to 0 means that the program has
> crashed, this happens from time to time with developers versions).
>
> Thus you should use 4.2 or 4.3 to get faster results. 

So I gather - but, I would prefer, at this point, to understand the 
underlying reasons for some of the time discrepancies for certain tests. 
Specifically, ac and aermod.

>   
> > In the following, I tabulate *my* results and compare those with those
> > posted on the polyhedron site for gfortran on an AMD box (Sun Galaxy
> > X4100 - Opteron 256 chips - 3 GHz).
> >     
> Could you tell what you mean by "posted"? I think there were several
> values posted at some point.
>
>   
On the polyhedron site (where else? ;-)

> There are essentially:
> - Nightly run: http://www.suse.de/~gcctest/c++bench/polyhedron/
> - Nightly run: http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/
> - Half-year runs: http://www.polyhedron.com/
> - http://gcc.gnu.org/ml/fortran/2007-02/msg00151.html
>
>   
> > (I'll skip the geometric mean, since I'm not convinced it means a
> > whole lot...).
> >     
>
>
> And doing a geometric mean is more meaningful in this case than an
> arithmetic mean.
>   
yes, I know (I do applied statistics for a living...). Still don't think 
its worth much alone - the pairwise assessment of differences is more 
meaningful. Less convenient than a single number, but more generally 
informative.

>   
> > 2. anyone had any luck doing 32-bit compilations (on this machine, I
> > should be able to do both 64- and 32-bit compilations - but adding the
> > -m32 flag causes things to crash and burn).
> >     
> Works here, but is ~5% slower than -m64. By the way, if you have a
> program whose runtime is relatively short and it is run often, using
> -fprofile-gen / -fprofile-use can speed up by around 1% to 4% depending
> on the program. (See
> http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/ for the
> comparison of -m64 with -m32 and -m64 with and without -fprofile-use.)
>   
Thanks - worth trying.

I'll try to post the error messages I get when I try -m32 compilation.

> Tobias
>
>
>