Re: different results with different f77 optimizers

Tom Keyes <keyes@chem.bu.edu> wrote:
: I am running some molecular dynamics simulations on an SGI 150 MHz
:'Challenger' with IRIX 5.2. I compile the Fortran source with f77
:-O3 -non_shared;if I try -O3 alone I get a message that the system does
:not support -O3 in 'shared' mode, please use non_shared. The program
:compiles and runs fine. Recently I recompiled with no optimizer,which I
:understand leads to the default '-O1'. Again the program compiled and
:ran fine-the same identical program-but now one of the calculated
:quantities was radically different. I have checked enough now to verify
:that these two different optimizers really do lead to different results.


This is not necessarily a bug. When you compile without optimization,
each assignment will be performed at the "obvious" place in the code,
and each reference to that variable will pull the value out of memory.


When you compile with optimization, the movement of results into memory
can be delayed until the next subroutine/function call that uses that variable
(or a variable equivilenced to it) or until the next subroutine/function
call if the variable is in common... or until the compiler needs the
registers for other purposes.. Sufficiently large routines may
be hard for the compiler to optimize if it tries to keep everything
in registers as long as possible, so there might come a point where the
compiler flushes to memory anyhow just so that it does not need
to keep track of the result anymore.


Whether a result is kept in a register or stored can make a difference to
the calculation, as storage and retrieval can result in a loss of precision
compared to the register case, particularily if single precision is used.
Even with double precision, loss of precision is possible, as internal
hardware registers may hold more bits than a double precision variable.
It is not uncommon, for example, to do calculations at 80 bits but for
double precision variables to be 64 bits long.




With programs such as molecular dynamics simulations, unless the program
has been specifically written to take precision problems into account,
these little differences end up making a big difference in the end.
This is particularily true if there are any matrix inversions involved
unless the matrices are known to be well-conditioned.




One must also be careful in FORTRAN as there is a bit of ambiguity
in the standards as to what order certain operations may/must be
carried out. This can result in different answers under different
optimization levels. The standard is fairly strict in banning regrouping
of what are normally considered algebraic associative operations, though,
the associative property does not hold on floating point numbers :-(


        Walter Roberson roberson@Ibd.nrc.ca
[Au contraire, the F77 standard said the compiler can regroup all it wants so
long as explicit parentheses are observed. But precision problems can be a
big issue. I'd also look and make sure the program doesn't have aliasing
problems, e.g. two arguments to a function that overlap. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.