At 12:11 PM 12/15/2003, Peter Shenkin wrote:

>Hi,
>
>Please be aware that any compilation for Pentium will work
>on Opteron;  Opteron is backwards-compatible with "normal"
>x86 builds.  Our normal Absoft x86 builds, done on Athlon
>or PIII, run just fine, and benchmark very well, on Opteron.
>
>There may be some special Opteron flags you can specify,
>but I doubt they'll do much.  For instance, the special
>Athlon flags make not a whit of difference when we benchmark
>our codes on Athlon.

To some people, the 15% or so of performance gained by using Opteron flags
is a whit of difference.  Those flags imply use of the larger set of
registers, choosing the faster among SSE/SSE/x87 instructions, including
parallel ones, and 128-bit alignment of local arrays.  The difference is
larger for codes which use the 64 bit integers, either in 64- or 32- bit
addressing modes.


>I suspect the only thing a 64-bit compilation will buy
>you on Opteron is extra address space, which is good if
>you need it.  But we have found on other platforms, such
>as IRIX64, that 32-bit executables actually run faster
>than 64-bit executables on the 64-bit OS, because of
>better cache warmth.  On AIX and IRIX, AFAIK, you get
>"64-bit numerical performance" even with a nominally
>32-bit executable.  I suspect that this is true on
>Opteron, too, because even 32-bit executables should
>be taking care of normal x86 80-bit floating-point
>registers.
>

All current mass produced CPUs have double precision hardware support.   In
years past, several 16-bit CPUs had double precision hardware, in case you
call that "64-bit numerical performance."  Some of them blurred the 16-bit
distinction by supporting a large number of address segments.  Or, do you
reserve your term for a machine which has more than 32-bit addressing
potentially available, even if it's not in use?  AFAIK, Opteron has 40-bit
physical, 48-bit virtual hardware addressing support in "64-bit" mode.  The
leading "64-bit" compiler for Opteron limits individual arrays, structures,
and common blocks to 2GB (31-bit addressing).  Code size is limited to 4GB,
to avoid loss of normal performance.  This is still advertised as a 64-bit
mode, since it is more than is supported on its 32-bit competitors.  Again,
in a sense, you have a number of distinct address segments, referred to as
"physical address extension" in at least one of the candidate OS.

That backwards compatibility is somewhat limited.  None of the MPI binaries
I have tested will run (at least not MP) on both an Opteron 64-bit OS and
on a 32-bit OS.  I have seen 32-bit applications built against a 32-bit mpi
which is specific to the Opteron 64-bit OS, running with a slight reduction
in performance from their 32-bit sisters running on a 32-bit OS on the same
Opteron.   I would think that some readers of this list would be interested
to know that you may not include MP applications in your blanket
statement.  Even if the differences relate to differences in threading
library support, rather than being inextricably linked to the different
addressing modes, they are big enough differences to break compatibility in
practice.   Evidently, the advantages of the Opteron are sufficient to
motivate people to deal with these differences, but they should not be
ignored.   No more than I can ignore the fact that I can't read those
Apple-mail Christmas greetings from my relatives with a linux or Windows
reader, other than by going to "view source."     Is different necessarily
better?


Tim Prince