Re: Large slowdown with gfortran vs f77 (x7)

Re: Large slowdown with gfortran vs f77 (x7)

[FX]

Hi Jeremy,

   -- it's unarguably a glibc issue: if exp() is fast and expf() is  
slow, why doesn't glibc implement expf() by calling exp()? (yes, there  
can be other issues like rounding or so, but they can also be dealt  
with separately)
   -- a similar bug was already reported a year and a half ago, and no  
activity was recorded on that front  (http://sources.redhat.com/bugzilla/show_bug.cgi?id=5997 
); overall, the math lib from glibc can be buggy and slow (and its  
development is not exactly proceeding at a steady pace) but political  
reasons prevent GCC to include its own math lib
   -- there is a GNU Fortran mailing-list where Fortran-related issues  
are welcome

Regards,
FX

Re: Large slowdown with gfortran vs f77 (x7)

[Tobias Burnus]

On 09/04/2009 05:04 PM, FX wrote:
>   -- it's unarguably a glibc issue: if exp() is fast and expf() is
> slow, why doesn't glibc implement expf() by calling exp()? (yes, there
> can be other issues like rounding or so, but they can also be dealt
> with separately)

If I recall correctly, it is mostly an x86-64 problem. AMD has some math
patches for GLIBC which speed things up a lot. I think those are used in
openSUSE/SLES but not in Fedora. On the other hand, the AMD patches have
a problem with signaling NaN, which is being fixed [1,4].

Some older timings (from PR 34128) on openSUSE (!)  -- for "sin" but
there is the same problem as for exp:

              g77     gfortran
-m32  real(4) 0.408s  0.421s
-m64  real(4) 1.040s  0.589s ! sinf on x86-64: 40% faster!
-m32  real(8) 0.411s  0.408s
-m64  real(8) 0.976s  0.968s ! sin on x86-64


As this is a math-library problem, one cannot do much from the
GCC/gfortran side. You could consider using the AMD Math Core Library
[2] which implements fast versions of the trigonometric functions and
exp [3]. Those functions are not fully IEEE compliant but it might not
be needed in your case [3,4]. (See AMCL manual [3] for the details.)
Intel's MKL should have something similar if you are on Intel hardware
and have by chance the library.

Switching to SUSE or applying the patches oneself is another
possibility. (I do not know why the patches are not included in the
upstream version of glibc. There must be some (somewhat) well-founded
reason.)

> -- a similar bug was already reported a year and a half ago, and no
> activity was recorded on that front 
> (http://sources.redhat.com/bugzilla/show_bug.cgi?id=5997);

Well, it is assigned to someone @suse and as written it is not an issue
on openSUSE. It might be also related to the AMD patches and the reason
why they are not included in GLIBC.

Tobias
(who uses openSUSE [11.1/Factory] at home, Fedora [version 6 (!)]  at work)


[1] For sNaN, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39314 and
https://bugzilla.novell.com/show_bug.cgi?id=487576
[2] ACML (free as in free beer): http://www.amd.com/acml
[3]
http://developer.amd.com/cpu/Libraries/acml/onlinehelp/Documents/Simple.html
; the functions are prefixed by "fast" but if you include the library
before the math library ("-lm") the fast version is used instead of the
libm version; "-lm" is automatically appended (internally) at the end of
the command line when using "gfortran" thus simply adding "-lacml_mv"
(or was it -lacml ?) to the command line should be sufficient.
[4] Note, the GLIBC patches of AMD are supposed to be fully IEEE
complient while the fastexp etc. of ACML are not (esp. regarding
denormal numbers and signaling NaN.)

Large slowdown with gfortran vs f77 (x7)

[Jeremy Sanders]

Hi - We noticed some code was very slow in gfortran vs g77, almost a factor 
of 7 times slower. This appears to be because gfortran uses the expf 
liubrary function call for the fortran exp() function for single precision 
numbers, but g77 uses the exp library function (i.e. the double precision 
function).

You can see the very large speed differences by telling gfortran to always 
use double precision numbers.

This can be replicated with this simple program:

test.f:
      implicit none
      integer i,j
      real a, u
      do j=1,10
         do i=1,10000000
            a=exp(1.0+1.0/i)
            u = u+a
         end do
      end do
      print *,u
      end

Compiled with gfortran -O2:
real    0m29.921s
user    0m29.912s
sys     0m0.000s

Compiled with gfortran -O2 -fdefault-real-8:
real    0m4.306s
user    0m4.304s
sys     0m0.000s

This is with a newly built gcc 4.4.1 on Fedora 10 (glibc 2.9), x86-64.

As the difference comes down to the speed difference between exp and expf, 
is it a gcc issue or a glibc issue? Should gcc be using this slow function? 
It seems amazing that the same function call is 7 times slower for lower 
precision numbers!

Thanks

Jeremy

-- 
Jeremy Sanders <jss@ast.cam.ac.uk>   http://www-xray.ast.cam.ac.uk/~jss/
X-Ray Group, Institute of Astronomy, University of Cambridge, UK.
Public Key Server PGP Key ID: E1AAE053

Re: Large slowdown with gfortran vs f77 (x7)

[James Cloos]

>>>>> "Jeremy" == Jeremy Sanders <jss@ast.cam.ac.uk> writes:

Jeremy> You can see the very large speed differences by telling gfortran
Jeremy> to always use double precision numbers.

Jeremy> This can be replicated with this simple program:

Jeremy> Compiled with gfortran -O2:
Jeremy> real    0m29.921s
Jeremy> user    0m29.912s
Jeremy> sys     0m0.000s

Jeremy> Compiled with gfortran -O2 -fdefault-real-8:
Jeremy> real    0m4.306s
Jeremy> user    0m4.304s
Jeremy> sys     0m0.000s

Jeremy> This is with a newly built gcc 4.4.1 on Fedora 10 (glibc 2.9), x86-64.

I tried it on my 1Ghz PIII laptop running Gentoo with gcc 4.1.1 and
glibc 2.10.1.

I added -march=pentium3 to the gcc cmd line; that probably made little
difference.  (glibc was also compiled with -march=pentium3 -O2).

I got nearly identical user times for the two compiles; user time was
always within 0.03 of 23.40 over multiple runs.

Incidently, while the real-8 compile output 271828665.96115601, the
real4 compile output 67108976.

This does, then, seem to be an x86-64 issue.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6