Compiler performances under Opteron

The combantants were the Intel compiler, the Gcc compiler, and the Portland
Group compiler:

http://www.digit-life.com/articles2/...-opteron2.html

On Mon, 01 Sep 2003 03:06:08 GMT, "Yousuf Khan"
<> wrote:
>The combantants were the Intel compiler, the Gcc compiler, and the Portland
>Group compiler:
>
>http://www.digit-life.com/articles2/...-opteron2.html

Hmm, interesting. A similar comparison is available from AMD's own
SPEC submissions, but the results are slightly different. AMD
submitted quite a lot of SPEC CINT2000 results for their Opteron 144
chip (1.8GHz). Here are the links to a few of them:

SuSE i386/Intel C
http://www.spec.org/cpu2000/results/...421-02087.html

SuSE AMD64/Intel C
http://www.spec.org/cpu2000/results/...421-02097.html

SuSE i386/gcc 32-bit
http://www.spec.org/cpu2000/results/...421-02090.html

SuSE AMD64/gcc 32-bit
http://www.spec.org/cpu2000/results/...421-02096.html

SuSE AMD64/gcc 64-bit
http://www.spec.org/cpu2000/results/...421-02093.html

And finally
Windows 2003/Intel C/Smartheap Library
http://www.spec.org/cpu2000/results/...421-02108.html


The best results of all were received with the last combination,
probably due to the Smartheap library as much as anything else. Where
things really differ from the first article though is that AMD found
that going to a 64-bit operating system still improved performance
even with 32-bit code when using GCC. The Intel compiler was a little
slower on a 64-bit OS, but not by a very significant amount. AMD also
saw less of an increase going from 32-bit to 64-bit code it seems.

Unfortunately AMD's SPEC CFP2000 results are not nearly as complete,
they only tested with the Intel compiler. However, IBM does have a
brand new submission of their e325 server using an Opteron 246
(2.0GHz) processor. They used a combination of the GCC C compiler and
the PGI Fortran compiler. The results of that are here:

SuSE AMD64/GCC C 64-bit/PGI Fortran 64-bit
http://www.spec.org/cpu2000/results/...728-02417.html

The result of 1172/1180 (base/peak) compared rather favorably to the
results from Intel's compiler.

SuSE AMD64/Intel C/Intel Fortran
http://www.spec.org/cpu2000/results/...421-02098.html

Now this last system used only a 1.8GHz Opteron 144 processor as
opposed to the 2.0GHz Opteron 246 of the IBM systems, so the Intel
compiler is actually faster at 1093/1162. Doing a bit of guesstimate
scaling, a 2.0GHz Opteron should score about 1175/1250.


Ok, so after all those links and numbers, what can we make of all
this? Err, well.. I suppose there are a lot of conclusions you could
make, depending on just which numbers you decide to look at. The
first thing that is clear though is that simply going to a 64-bit
operating system isn't going to do much (if anything) for the
Opteron's performance. It's also clear that compiling code for AMD64,
while it will generally improve performance, can actually degrade
performance in some situations.

Another important bit of info we can see here is that GCC is a pretty
darn good compiler. It might not be quite as fast as Intel's latest
and greatest compiler, but it isn't far off at all.

It is also worth noting that if you have a very processor-intensive
bit of code to run, choosing the right compiler could be just as
important, or possibly even more important than choosing the right
processor.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

On Mon, 01 Sep 2003 06:28:41 +0000, Tony Hill wrote:

> Where
> things really differ from the first article though is that AMD found
> that going to a 64-bit operating system still improved performance
> even with 32-bit code when using GCC.

On Linux, this makes sense as most kernels are compiled with HIMEM enabled
(to enable use of more than 960M of RAM), which pays a 5-10% penalty. On a
64 bit processor that HIMEM trick is not needed, as the kernel can easily
map all memory in the available address space (that is, as long as you
don't have over 64TB of RAM or something )

"Tony Hill" <> wrote in message
news:562bc414416d1366fba3386821cd59f2@news.1usenet .com...
> Hmm, interesting. A similar comparison is available from AMD's own
> SPEC submissions, but the results are slightly different. AMD
> submitted quite a lot of SPEC CINT2000 results for their Opteron 144
> chip (1.8GHz). Here are the links to a few of them:
>
> SuSE i386/Intel C
> http://www.spec.org/cpu2000/results/...421-02087.html
>
> SuSE AMD64/Intel C
> http://www.spec.org/cpu2000/results/...421-02097.html
>
> SuSE i386/gcc 32-bit
> http://www.spec.org/cpu2000/results/...421-02090.html
>
> SuSE AMD64/gcc 32-bit
> http://www.spec.org/cpu2000/results/...421-02096.html
>
> SuSE AMD64/gcc 64-bit
> http://www.spec.org/cpu2000/results/...421-02093.html
>
> And finally
> Windows 2003/Intel C/Smartheap Library
> http://www.spec.org/cpu2000/results/...421-02108.html
>
>
> The best results of all were received with the last combination,
> probably due to the Smartheap library as much as anything else. Where
> things really differ from the first article though is that AMD found
> that going to a 64-bit operating system still improved performance
> even with 32-bit code when using GCC. The Intel compiler was a little
> slower on a 64-bit OS, but not by a very significant amount. AMD also
> saw less of an increase going from 32-bit to 64-bit code it seems.

Not entirely aware of the technology behind compilers. So assuming that
Intel is going to do as little as possible to help AMD out, and it's
certainly not going to create an AMD64 compiler, then how exactly do they
get the Intel compiler to spew out AMD64 binaries? Are all of the 64-bit
code only inside the libraries, and therefore all code is simply a call to
some function within the library? Or are there modules that AMD can install
in the compiler that makes it spew out the required AMD64 code?

I assume that the Intel compiler is itself a 32-bit binary completely
unaware of 64-bit mode. So it must be cross-compiling to to AMD64.

Yousuf Khan

On Mon, 01 Sep 2003 17:00:00 GMT, "Yousuf Khan"
<> wrote:
>Not entirely aware of the technology behind compilers. So assuming that
>Intel is going to do as little as possible to help AMD out, and it's
>certainly not going to create an AMD64 compiler, then how exactly do they
>get the Intel compiler to spew out AMD64 binaries? Are all of the 64-bit
>code only inside the libraries, and therefore all code is simply a call to
>some function within the library? Or are there modules that AMD can install
>in the compiler that makes it spew out the required AMD64 code?
>
>I assume that the Intel compiler is itself a 32-bit binary completely
>unaware of 64-bit mode. So it must be cross-compiling to to AMD64.

The code is pure 32-bit x86 (IA-32) that is being spit out by the
compiler. However the operating system (or the kernel at least) on
which it was installed is 64-bit. The libraries are where things get
tricky, and I believe that Linux and Windows are taking very different
approaches here. My understanding is that Windows uses a sort of
abstraction compatibility layer in between the 32-bit application and
the 64-bit libraries. Under Linux it seems like there are simply two
sets of libraries, one for 32-bit code and one for 64-bit code.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

"Tony Hill" <> wrote in message
news:3a52ae975ecbbe1736a797240020b52d@news.1usenet .com...
> >I assume that the Intel compiler is itself a 32-bit binary completely
> >unaware of 64-bit mode. So it must be cross-compiling to to AMD64.
>
> The code is pure 32-bit x86 (IA-32) that is being spit out by the
> compiler. However the operating system (or the kernel at least) on
> which it was installed is 64-bit. The libraries are where things get
> tricky, and I believe that Linux and Windows are taking very different
> approaches here. My understanding is that Windows uses a sort of
> abstraction compatibility layer in between the 32-bit application and
> the 64-bit libraries. Under Linux it seems like there are simply two
> sets of libraries, one for 32-bit code and one for 64-bit code.

So when they are comparing the Intel performance under 32-bit Linux and
64-bit Linux, then we are simply talking about 32-bit applications
performance under either a 32- or 64-bit OS, right?

Yousuf Khan

On Mon, 01 Sep 2003 03:06:08 GMT, "Yousuf Khan"
<> wrote:

>The combantants were the Intel compiler, the Gcc compiler, and the Portland
>Group compiler:
>
>http://www.digit-life.com/articles2/...-opteron2.html
>

Let the buyer beware. When you are benchmarking, you are testing
three things: the hardware, the compilter, and the person using the
compiler.

Life used to be fairly simple: you chose an optimization switch -Ox,
where x varied from (say) 0 to 3. Not so anymore. Not familiar with
the Portland group compiler, but gcc and icc have about a zillion
different combinations of switches.

How the compiler handles SIMD instructions is important. gcc is almost
completely crippled for SSE2 at the moment, although they keep trying.
The capabilities of gcc change almost daily.

Simple tricks can change whether a loop vectorizes or not. That
doesn't make much difference if the compiler can't properly support
SSE2, but it makes a big difference for icc.

That doesn't even touch the subject of feedback-directed optimization,
at which at least icc is already starting to show some muscle.

I've seen Intel and "independent" testers get completely different
results for icc and the P4, and I don't believe the difference is that
Intel cheated, unless you consider going to extraordinary lengths to
wring performance out of a compiler cheating.

Throw into the mix the x86-64 instruction set extensions, and you have
a recipe for nearly complete unintelligibility. I'm not saying that
throwing code onto the compilers and seeing what they can do isn't
worth the effort, but it's way too early to draw even preliminary
conclusions.

People in the Linux community have felt that Intel would be better off
open-sourcing icc. It's easy to see why they didn't. Had they done
so, someone would have already built an x86-64 code generator for it,
and that's another reason why Intel is never going to implement
x86-64, almost no matter how much heat they get from Opteron.

RM

"Robert Myers" <> wrote in message
news:...
> How the compiler handles SIMD instructions is important. gcc is almost
> completely crippled for SSE2 at the moment, although they keep trying.
> The capabilities of gcc change almost daily.

So what exactly are the problems the gcc folks are having with SSE2
instructions?

Yousuf Khan