The next benchmark is run with the optimization flags:

Finally, we have the architecture optimized flags as well:

You are reading these charts correctly, the O3 flag actually penalizes the AMD CPU.  We also compiled the program with -O2 -march=k8 but we got virtually the same score with or without the march flag.

We were informed others have been capable of much faster nodes per second using GCC 3.4.1 and the flagset:

We did not have time to fully test GCC 3.4.1, although there is a strong likelihood that 3.4 encourages better optimizations (particularly on the x86_64 platforms).

Crafty

For good measure, we have included Crafty into our chess benchmarks section.  Crafty was only built using the "make linux-amd64" target.  From the Makefile, it seems as though the "AMD64" moniker is slightly inappropriate.  The target claims:

The benchmark was generated by running the "bench" command inside the program.

It is clear the difference between both processors is quite severe in this instance.  Although it is difficult to pin an exact culprit, there are likely multiple arch optimizations were left untapped, and thus our reasoning for discouraging overusage of optimizations in general.

Mental Ray

Between Mental Ray and POV-Ray, we should see our largest taxing of the floating point in a real world scenario. 

We ran Mental Ray 3.3.3 from the command line on the same benchmark file we have been using in the past. Unfortunately we do not have access to 64-bit Maya/Mental Ray binaries at this time, but we are working with AW.

The Opteron outperforms the Nocona in this benchmark but we would like to see x86_64 tests in the future.

POV-Ray

POV-Ray was installed from RPM, and then run against the official benchmark.ini.

As we can see above, the difference between the two CPUs seems exaggerated and difficult to trust.  We are working with the POV-Ray team to determine why the differences are so dramatic.

Opstone

Since our use of Ubench in the previous article clearly infuriated many people, we are going to kick that benchmark to the side for the time being until we can decide a better way to implement it. 

In the meantime, a reader suggested we give Blue Sail Software's Opstone benchmarks a try.  In this portion of the review, we will use their precompiled optimized binaries of the Scalar Product (SP) and Sparce Scalar Product (SSP) benchmark.  The SP benchmark is explained by the author: 

Note that we ran the P4 optimized binaries on the Nocona, which did not provide x86-64 enhancements.  Running the AMD64 binaries on the Xeon yielded poor results. The P4 Opstone binaries are the only 32-bit binaries used in this analysis.

Below is the SSP benchmark, as explained by the author:

There is a general distrust of synthetic benchmarks, so take this portion of the analysis only with a grain of salt.  We see a tale of two processors in these graphs; generally the Xeon performs better in the raw operation SP benchmark, while the Opteron performs better in the condition testing SSP benchmark. We would be lead to believe the Intel processor does content integer content creation better than the Opteron, and visa versa with floating point applications. However as we see in the rest of the review, this is not always the case.

lame

If our other benchmarks were any indication, compiler flags seem to make or break our analysis of a processor.  However, lame 3.96.1 seemed one of those programs that did not readily enjoy optimizations; at least with the test file we used.  When we attempted to force any optimization, even - march or - O2, lame appeared to produce the same or worse results.

GZip

GZip was installed straight from RPMs, so optimization flags are probably minimal. We used the 700MB test file from the lame encoding test as dummy data.

 This becomes our first real world test where we see Intel come out ahead.  This coincides with what we saw on the previous page with the synthetic benchmark. 

John The Ripper

We are using John the Ripper 1.6.37 in this portion of the benchmark.  As a few extremely knowledgeable readers pointed out, the "stable" 1.6 branch of code relies heavily on hand coded ASM which by today's standards is fairly ancient anyway.  Using the "development" branch, we are able to tweak the options enough to get away from any ASM. 

However, if our chess benchmarks were any indicator, optimization flags tend to skew the results dramatically.  As a result, we run three trials of the John the Ripper (JTR) benchmark each using different compile flags.  Configuration 1 is in the standard "make linux-x86-64" target.

From looking at the graphs, it becomes easy to see why JTR makes a difficult program to use as a benchmark.  Pay careful attention to each benchmark, particularly in between the -O2 and -O3 compile options. 

OpenSSL

We couldn't think of a good way to post the OpenSSL benchmarks, so we just put both comparisons into text files which you may download here (AMD) and here (Intel). The reader is left to draw their own conclusions.

Although this latest attempt to produce an accurate, unbiased, real world comparison of these two processors is likely more thorough than the review earlier this week, there are still critical issues we will address to get out of the way.

First of all, AMD's Opteron 150 is the highest performing AMD workstation CPU money can buy. Thus, it is priced around $600 at time of publication.  (The nearly identical FX-53 is priced slightly higher). Intel's Xeon 3.6GHz / Pentium 4 3.6F processor is the highest performing Intel workstation CPU money can't buy; although it has shown up in various OEM channels, it really has not hit the market in full force yet.  When it does, we are expected to see it retail for $850.  This automatically raises the question as to whether or not these two are directly competing processors.  Since prices in the market fluctuate daily depending on vendor stock with such high end CPUs, we leave that decision up to the reader.

Secondly, GCC 3.3.3 optimizations became a larger than expected variable in these tests.  As shown in the TSCP benchmark, changing the optimization flags wildly changed performance of the Opteron CPU, while the Nocona only received mild benefits.  We also hear that GCC 3.4 tends to increase performance on the Opteron CPUs even further, although we ran out of time to complete that test.

After all is said and done it became difficult (nearly impossible?) to justify the Xeon processor in a UP configuration over the Opteron 150, but perhaps we will see significant changes in dual and four way configurations.  We have Linux benchmark shootout between the two processors coming up, as well as a Windows analysis too. 

Once again special thanks to Super Micro for providing us with the hardware on such short notice for this review.