1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Compiler performances under Opteron

Discussion in 'Intel' started by Yousuf Khan, Sep 1, 2003.

  1. Yousuf Khan

    Yousuf Khan Guest

    Yousuf Khan, Sep 1, 2003
    #1
    1. Advertising

  2. Yousuf Khan

    Tony Hill Guest

    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/insidespeccpu/insidespeccpu2000-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/res2003q2/cpu2000-20030421-02087.html

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

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

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

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

    And finally
    Windows 2003/Intel C/Smartheap Library
    http://www.spec.org/cpu2000/results/res2003q2/cpu2000-20030421-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/res2003q3/cpu2000-20030728-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/res2003q2/cpu2000-20030421-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
     
    Tony Hill, Sep 1, 2003
    #2
    1. Advertising

  3. 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 :) )
     
    Divin Marquis, Sep 1, 2003
    #3
  4. Yousuf Khan

    Yousuf Khan Guest

    "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/res2003q2/cpu2000-20030421-02087.html
    >
    > SuSE AMD64/Intel C
    > http://www.spec.org/cpu2000/results/res2003q2/cpu2000-20030421-02097.html
    >
    > SuSE i386/gcc 32-bit
    > http://www.spec.org/cpu2000/results/res2003q2/cpu2000-20030421-02090.html
    >
    > SuSE AMD64/gcc 32-bit
    > http://www.spec.org/cpu2000/results/res2003q2/cpu2000-20030421-02096.html
    >
    > SuSE AMD64/gcc 64-bit
    > http://www.spec.org/cpu2000/results/res2003q2/cpu2000-20030421-02093.html
    >
    > And finally
    > Windows 2003/Intel C/Smartheap Library
    > http://www.spec.org/cpu2000/results/res2003q2/cpu2000-20030421-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
     
    Yousuf Khan, Sep 1, 2003
    #4
  5. Yousuf Khan

    Tony Hill Guest

    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, Sep 1, 2003
    #5
  6. Yousuf Khan

    Yousuf Khan Guest

    "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
     
    Yousuf Khan, Sep 2, 2003
    #6
  7. Yousuf Khan

    Robert Myers Guest

    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/insidespeccpu/insidespeccpu2000-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, Sep 2, 2003
    #7
  8. Yousuf Khan

    Yousuf Khan Guest

    "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
     
    Yousuf Khan, Sep 6, 2003
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Vince
    Replies:
    2
    Views:
    856
    AideInfo
    Oct 19, 2003
  2. Replies:
    2
    Views:
    464
    Robert Lacoste
    Jan 16, 2006
  3. Olindo Pindaro

    Performances of SATA-ATA of Asus?

    Olindo Pindaro, Aug 18, 2003, in forum: Overclocking
    Replies:
    13
    Views:
    556
    Keith Clark
    Aug 19, 2003
  4. Petter Gustad
    Replies:
    5
    Views:
    429
    Petter Gustad
    Dec 8, 2006
  5. time
    Replies:
    0
    Views:
    395
Loading...

Share This Page