Slashdot Mirror

← Back to Stories (view on slashdot.org)

EM64T Xeon vs. Athlon 64 under Linux (AMD64)

Posted by Hemos on from the pressing-the-limits-of-the-machines dept.

legrimpeur writes "Anandtech has a nice performance comparison under Linux (AMD64) between the recently introduced 3.6GHz EM64T Xeon processor and an Athlon 64 3500+. It is disappointing to see how the Athlon gets trounced in FPU intensive benchmarks. No memory-bound benchmarks (where the Athlon is supposed to have an edge) are presented, though." Update: 08/09 23:34 GMT by T : As the Inquirer reports, many Anandtech readers take issue with the comparison.

3 of 313 comments (clear)

  1. Comment removed by account_deleted · · Score: 5, Informative

    Comment removed based on user account deletion

  2. Re:Math Co-Processor by ergean · · Score: 5, Informative

    They have a cross licence agreement, so each one has what the other has in production in the term of 6 to 9 months. That is why we see the SSE in AMD processors, and AMD64 instruction in Intel64 processors.

    http://contracts.corporate.findlaw.com/agreement s/ amd/intel.license.2001.01.01.html

    So I don't see any problem fro AMD in licensing the cp-processor.

  3. Re:FPU intensive? by kent.dickey · · Score: 5, Informative

    The "primegen" program listed where the Xeon beats the Athlon slightly does not do any floating point.

    I looked at the code and played with it a little (I got it from http://cr.yp.to/primegen.html and it seems the benchmark is mostly limited by the implementation of putchar().

    My system was an dual AMD Opteron 1.8GHz running Win XP pro with Cygwin. I modified the benchmark to not use putchar() but instead just write the characters to a 1MB buffer, and it got 16 times faster! To be specific, "primes 1 100000000 > file" went from 24.2 seconds to 1.497. Note that it's generating 51MB of output for primes under 100 million. I didn't bother running it for the 100 billion max, but would expect it to be around 50GB.

    This is a very poor benchmark since it's just measuring your stdc implementation of putchar and your system's ability to sink data to /dev/null, not anything useful.