Subject: single-precision "expf" super slow on x86-64??

Miles Bader
Sun Apr 29 05:00:00 GMT 2012

Hi, I've run into the following very odd behavior:

On my debian x86-64 system, the single-precision "expf" function seems
to be about six times _slower_ than the double-precision "exp"

Moreover, "expf" seems to be far slower than other "slow" math
functions (sin, cos, etc) while "exp" seems to be roughly the same
speed as them.

I first noticed this in a real program, which seemed oddly slow, and
got it to speed up significantly by using exp instead of expf (even
though the values being manipulated are all single-precision, so I
don't need exp).

I've duplicated this in the attached test program; here's the output:

   $ gcc-4.7 -o exp-test -O2 -march=native exp-test.c -lm

   $ ./exp-test
   fisum = 4.99891e+06, disum = 4.99891e+06
   fosum = 1.71808e+07, dosum = 1.71808e+07
   float (expf) user time: 2.94819 sec
   double (exp) user time: 0.520032 sec

The first two lines of output just verify that the results are the
same for float and double calculations.  The second two lines show the
user CPU times (via getrusage), showing that "expf" takes about six
times as long as "exp"...

The glibc version is 2.13, the compiler is gcc 4.7 (compiling for
x86-64), and the CPU is an AMD Phenom.

Anybody have any idea what's going on?  This behavior seems very

[As a workaround, I could modify my program to just use "exp", even on
single-precision values, but this seems a fragile hack, and detecting
this odd situation with autoconf seems ... annoying...]



-------------- next part --------------
A non-text attachment was scrubbed...
Name: exp-test.c
Type: text/x-csrc
Size: 1613 bytes
Desc: program to time libm "exp" and "expf" functions
URL: <>
-------------- next part --------------

Corporation, n. An ingenious device for obtaining individual profit without
individual responsibility.

More information about the Libc-help mailing list