DEXP/DLOG/DSQRT running slowly
Sun Studio 11: f90 compiler
DEXP/DLOG/DSQRT calls can go very slowly when the argument is close to 1.
Machine type = x86_64
Operating system: Red Hat Linux
Sample program (derived from part of the Fortran Whetstone benchmark program):
double precision X,T1
IXTRA = 2500
N8 = 20000
T1 = 0.50000025D0
X = 0.999D0
DO 80 IX=1,IXTRA
if (mod(IX,100).eq.0) write (*,22) IX, X
22 format (I4,' ',f15.12)
DO 80 I=1,N8
X = DSQRT(DEXP(DLOG(X) / T1))
80CONTINUE
stop
end
After about 1500 runs of the outer loop, when X becomes 0.999999999833, it slows down considerably - noticeable if the output is sent to a terminal.
This slowing down does not happen with the Intel 'ifort' compiler on the same computer.
[820 byte] By [
fcc7790] at [2007-11-26 9:43:20]
# 1
Both Intel and Sun rely on libm (part of the platform) to contain
implementations of these functions, so it is indeed unexpected to see such
an anomaly.
Well, first let's check that you're comparing apples with apples.
Is your code 32bit or 64bit?
You said that the machine type is x86_64, which means that the Sun compiler
will have chosen to build a 64bit program if you relied on the default.
One way to check:
% f90 foo.f
% file a.out
a.out: ELF 64-bit LSB executable, ...
I am less familiar with the Intel compiler. Can you use "file" to check your a.out?
# 2
> Well, first let's check that you're comparing apples with apples.
> Is your code 32bit or 64bit?
>
> You said that the machine type is x86_64, which means that the
> Sun compiler will have chosen to build a 64bit program if you
> relied on the default.
> One way to check:
> % f90 foo.f
> % file a.out
> a.out: ELF 64-bit LSB executable, ...
With the Sun Studio compiler:
% f90 esl99.f -o esl99
% file esl99
esl99: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
> I am less familiar with the Intel compiler. Can you
> use "file" to check your a.out?
With the Intel 'ifort' compiler:
% ifort esl99.f -o esli99
% file esli99
esli99: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped
# 3
Ok, so this is the 64bit case, thanks.
If I could impose on you again ... which version of ifort were you running?
("ifort -V" should do it). Just want to make sure we have a chance to duplicate your
observations.
I may have misled you a bit ... for 64bit codes it may well be that ifort and
Sun f90 are using different math libraries (libm). In general, results of
libm-intensive codes like yours might vary from one Linux to another because Sun
relies on the underlying platform.Our math expert tells me that double
precision -3.3301145180291890E-10 is a particularly hard number for exp
to compute a correctly rounded value to, and that's the math function you're
repeatedly evaluating when X becomes 0.999999999833 .
The libm that Sun is using, the one on your platform, apparently is spending
a little extra time on that value to give you the best rounded result it can.
If that's not what you want, we could explore ways to substitute other math
libraries with different tradeoffs between rounding and performance.
Or you might want to add a declaration
DOUBLE PRECISION OLDX, OLDTEMP
and replace
X = DSQRT(DEXP(DLOG(X) / T1))
by
OLDX = X ; OLDTEMP = TEMP
TEMP = DLOG(X)/T1
IF (TEMP .EQ. OLDTEMP) THEN
X = OLDX
ELSE
X=DSQRT(DEXP(TEMP))
to avoid hammering the hard case over and over.
# 4
> If I could impose on you again ... which version of> ifort were you running?> ("ifort -V" should do it).Version 9.1
