This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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]

Re: gfortran 4.3.2 about 3x slower than g77 for scientific application


Here are some timings:
(gfortran)
-O3 -march=native -ffast-math -funroll-loops = 37.914s
-O3 -march=native -funroll-loops = 37.914s = 36.99s
-O2 -march=native = 33.6s
-O2 -march=native -ffast-math = 32.5s

g77
-O2  = 8.957s

I should note actually that the outputs from g77 and gfortran are NOT
the same... I thought that they were but I didn't look closely enough.
Oops. The program is indeed iterative, and takes a few more iterations
than the g77 version (16 as against 11), however this is not
sufficient to explain the slowdown. The program does not utilise
random numbers and so should be deterministic. I am curious as to why
there is a difference between g77 and gfortran (even not using
-ffast-math).

Hmm this is very confusing.

I would be happy to continue using g77.... except it doesn't support
OpenMP. GRR.

Julian

On Thu, May 14, 2009 at 12:25 AM, Tobias Burnus <burnus@net-b.de> wrote:
> VelocideX wrote:
>> Executing the program on identical data is about 3x slower in gfortran than
>> g77 (v3.3.3-hammer).
> That's quite a lot. I don't know how gfortran compares with g77 (I have
> too much Fortran 90+ code), but typically I saw that the fastest
> other-vendor compilers are 8% to 25% faster - up to twice as fast for
> single tests. (However, for other test files, gfortran is twice as fast
> and if one looks at the geometric mean results of several compilers at
> http://www.polyhedron.co.uk/compare0html, one sees it does on average
> quite well and ranks speedwise in the middle.)
>
> Regarding g77, I got the impression that -O2 optimized a bit more
> aggressively in GCC 3.x than in GCC 4.x, which with -O3 GCC 4.x was
> usually faster.
>
>
> Julian King wrote:
>> -march=native makes negligible difference to the running time.
>>
> Which is expected for x86-64 as it is new enough that the capabilites of
> all CPUs are comparable. It would be interesting to see the results with
>
> ?-march=native -O3 -ffast-math -funroll-loops
>
> Unfortunately, it is in general non-trivial to find the cause of
> performance bottlenecks. It can already be difficult if one uses the
> same compiler and the versions are closer together (e.g. 4.3.0 vs.
> 4.4.0 ?- or even 4.5-devel-March08 vs. 4.5-devel-May09). If the
> algorithm is not stable and thus the convergence is influenced by minor
> numerical differences, the problem even gets larger.
>
> In this regard: How does the program perform with other compilers (if
> you happen to have them installed somewhere)? That way one can get an
> indication whether g77 is simply lucky and the fastest one or whether
> gfortran does particularly bad ?on your program.*
>
> Tobias
>
> * I had such a problem with one of my programs - with all compilers
> (gfortran, g95, ifort, NAG f95, maybe also openf95 I don't recall) the
> runtime was about 18s but with sunf95 40s; SUN finally traced it to be a
> rounding mistake. Instead of doing "real -(round)-> integer" for
> something like "INT(real_var)", sunf95 did "real --(round)-> integer
> --(convert)-> real --(convert)--> integer". Fixing the single bug made
> the sunf95-compiled program exactly twice as fast. (Actually it was not
> INT but some intrinsic to round down or up to the closest integer, but I
> forgot which one.)
>


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