Synthetic Benchmarks

Our Nocona server was setup in a remote location with little access, so we had limited time to run as many real world benchmarks as we are typically accustomed to. Fortunately, there are multitudes of synthetic benchmarks that we can use to deduce information quickly and constructively.

Sieve of Atkin (primegen)

Primegen is an older, but still useful library for generating prime numbers in order using the Sieve of Atkin. We compiled the Bernstein implementation by simply running "make". We ran the program as so:

# time ./primes 1 100000000000 > /dev/null

primegen 0.97

We found the benchmark to be extremely reliable and we replicated our figures continually with less than 1% difference.

Super Pi

We ran the Linux compilation of Super Pi 2.0, which is a closed source application. We are not aware of which optimizations are compiled with the program and we are prohibited from redistributing the binaries. Please download the latest binaries from ftp://pi.super-computing.org/Linux. We ran the command:

# ./super_pi 20

Below is the program's output of calculation time in number of seconds.

Super Pi 2.0

After re-running the program several times, our benchmarks never deviated outside of 1%. In a mathematical operation-only situation, the Intel processor has outpaced the AMD offering twice now.

Content Creation Synthetic Benchmarks (continued)
Comments Locked

275 Comments

View All Comments

  • Macro2 - Tuesday, August 10, 2004 - link

    John the Ripper results are completely invalid.

    The source code contains Hand-tuned ASSEMBLY routines, some of which only get called if the CPU has the word "Intel" in the name!!!!!

    (And others are optimized for the K6. LOL.)

    Totally bogus.

    See x86.S detect.c and best.sh in the source package.

    These results are garbage-- this "test" should be removed from the article.

    The architecture-detection code is also probably broken, even in the generic case.
    -----------------------T
    The big picture was that K Kubcki doesn't know jack about compiling software on Linux.

    He wrote a bogus Makefile, penalizing the K8 by 50%

    He ran "John the Ripper" without looking at the source code, and noting hand-tuned assembly routines which are only called if the CPU has the word "Intel" in the name. So that one's completely invalid.

    On top of that, he miscopied an earlier database result, again, against the K8.

    Then he formulated a bogus conclusion.

    The average user is not running miscompiled, largely irrelevant software.
  • eiger - Tuesday, August 10, 2004 - link


    hi all,
    I am new to this forum. Seems like an interesting
    debate. I am in the scientific computing business
    and over the past week I tried to benchmark the
    existing processors we have here to get a bearing
    on whether we should get the 3.4 GHz Xeon EM64T's or the opteron 248's for our new cluster (the prices seem to compare).

    My numerical code which is
    floating point intensive took about 6.60 seconds
    using the intel fortran compiler on an Intel Xeon 3.06 GHz, while it took 3.98 seconds with the
    portland groups fortran compiler (pgf90) on an opteron 246. Both were run 32-bit right now.
    Moving to 64-bit on the opteron improved the
    time by 0.2 seconds. Unfortunately I have no
    access to a 64-bit Xeon yet.

    Now using the intel fortran compiler gave 7.1s on the opteron and using pgf90 on the Xeon gave
    6.90s. So it seems like the opterons can still
    do better overall. pgf90 is versatile and can
    optimize for both processors well.


    Both machines have 2G RAM and 1 MB
    L2 cache.

    These are the highest end opteron and Xeon's I have access to at this moment.

    I would love to hear your comments and suggestions

    -j
  • eiger - Tuesday, August 10, 2004 - link

  • johnsonx - Tuesday, August 10, 2004 - link

    To avoid further misunderstanding, my statement from the last post:

    "I'm not arguing that an A64 isn't generally faster than a P4."

    Means that I agree that an A64 is generally faster than a P4.


  • johnsonx - Tuesday, August 10, 2004 - link

    JGunther,

    Sorry, your post is irrelavant to this discussion. Since the AT article in question is strictly about 64-bit mode, some other article comparing a regular 32-bit 3.6Ghz to A64 running 32-bit apps is irrelavant. I'm not arguing that an A64 isn't generally faster than a P4.

    Secondly, why are people here not grasping the FACT that a 3.6Ghz XEON EM64T and a Pentium 4 3.6F are the SAME for all practical purposes?

    It's not "justifying", it's stating a fact.

  • JGunther - Tuesday, August 10, 2004 - link

    johnsonx,

    Go read the comparison of an actual 3.6GHz P4 (not 3.6f, but who cares) vs. the s939 offerings.

    http://www.aceshardware.com/read.jsp?id=65000316

    AT did not just commit an act of bad journalism by comparing a server part to a desktop part, but as the numbers from Ace's Hardware review, AT's procedures are so bad and misrepresentitive, that it's downright fradulent.

    You can justify the comparison of the Xeon and the A64 all you want. It's a moot point though, since AT's results are so incredibly flawed.
  • johnsonx - Tuesday, August 10, 2004 - link

    To WiZzACkR,

    No sorry, you're still not making sense.

    If a $850 Intel server part and a $400 Intel desktop part are the same (just one is pinned and validated for DP use), then having the $850 server part 'stand-in' for the as yet unavailable $400 desktop part doesn't invalidate the comparison to a $350 AMD desktop part.

    To suggest an analogous situation, imagine AMD announced 2.6Ghz FX-55's and Opteron 152/252/852's. For sake of arguement, let's say pricing was $800 for the FX-55 and 152, $1000 for the 252, and $2200 for the 852 (no, I don't know if this is reasonable, but 8xx opterons are very expensive). Now, for whatever reasons AMD releases the Opterons ahead of the FX-55's, and AnandTech gets 4 852's for a server test. In another article, they use a single 852 to stand in for the soon to be available FX-55 and compare it to the currently available regular A64's, P4's and P4EE's.

    In that situation, would be make any sense to complain that a $2200 server chip was being compared to much cheaper desktop chips? No, of course not. It doesn't make any sense now either.

    An the desktop applications vs. server applications arguement is similarly pointless. Since the chips are the same, they run the apps the same.

    Remember again, this was a general preview of Intel's EM64T running a commercial desktop Linux distro.
  • JGunther - Tuesday, August 10, 2004 - link

    I personally would still like to know why this Nocona that they "got their hands on" is located in a server "in a remote location". What does this mean exactly?
  • Anemone - Tuesday, August 10, 2004 - link

    "I'm sorry Jim, I'm a doctor not a miracle worker! I'm truly sorry, but it's dead, there is nothing more anyone can do."

    *hands the next person the baseball bat*

    Anyone else feel utterly compelled to beat this horse further?
  • Zebo - Tuesday, August 10, 2004 - link

    KK

    Why did'nt you say in your conclusion... "the Midrange A64 desktop chip. costing $500 less, absolutly destroys intel's best 64 bit offering in all real world tests"

    hmmmm...

    Instead you focus on synthetics, screw them up, and draw inflamitory conclusion. Come on, be fair.

Log in

Don't have an account? Sign up now