SPECjbb 2005
SPECjbb 2005 simulates the role a server would play executing the "business logic" in the middle of a three-tier system with clients at the front-end and a database server at the back-end. The logic executed by the test is written in Java and runs in a JVM. This benchmark tests scaling with one to many threads, although its main score is largely a measure of peak throughput.

As you may know, system vendors spend tremendous effort attempting to achieve peak scores in benchmarks like this one, which they then publish via SPEC. We did not intend to challenge the best published scores with our results, but we did hope to achieve reasonably optimal tuning for our test systems. To that end, we used a fast JVM—the 64-bit version of Oracle's JRockIt JRE R27.6—and picked up some tweaks for tuning from recently published results. We used two JVM instances with the following command line options:

start /AFFINITY [0F, F0] java -Xms3700m -Xmx3700m -XXaggressive -XXlazyunlocking -Xlargepages:exitOnFailure=true -Xgc:genpar -XXgcthreads=4 -Xns3200m -XXcallprofiling -XXtlasize:min=4k,preferred=512k -XXthroughputcompaction

Notice that we used the Windows "start" command to affinitize our threads on a per-socket basis. We also tried affinitizing on a per-chip basis for the Xeon systems, but didn't see any performance benefit from doing so. The one exception to the command line options above was our Xeon L5430/San Clemente system. Since it had only 6GB of memory, we had to back the heap size down to 2200MB for it.

The Opteron 2384's performance here is undeniably impressive—a massive leap from the performance of the Opteron 2356, and substantially higher than its most direct competitor, the Xeon E5450. In fact, at just 2.7GHz, the Shanghai Opteron performs nearly as well as the exotic of the group, the 3.4GHz Xeon X5492, remarkably enough. Shanghai's larger L3 cache and other tweaks, combined with the Opteron's native quad-core design and strong system architecture, yield big returns in this server-class workload.

Not only that, but Oracle has hinted to us that even higher performance is possible when using a version of JRockIt optimized for Shanghai. That version of JRockIt hasn't yet been released, but we understand it's on the way.

Before we move on, let's take a quick look at power consumption during this test. SPECjbb 2005 is the basis for SPEC's own power benchmark, which we had initially hoped to use in this review, but time constraints made that impractical. Nevertheless, we did capture power consumption for each system during a test run using our Extech 380803 power meter. All of the systems used the same model of Ablecom 700W power supply unit, with the exception of the Xeon L5430 server, which used an FPS Group 460W unit. Power management features (such as SpeedStep and Cool'n'Quiet) were enabled via Windows Server's "Balanced" power policy.

Although it has the same 75W ACP rating as the Opteron 2356, the Opteron 2384 draws substantially less power at every step of the way. The Xeon E5450 system is practically a power hog by comparison, with much higher peak power draw. The bright spot for Intel here is the Xeon L5430/San Clemente system with DDR2 memory, whose power consumption is admirably low—almost 60W less than the Opteron 2384 system.

Have a look at what happens when we consider performance per watt.

Our Opteron 2384 system combines higher performance with lower power draw than the Xeon E5450 system, so its "bops per watt" lead is predictably large. Shanghai certainly looks good in this light.

Meanwhile, the Xeon L5430 aims to steal the limelight. It's a bit of a wild card, with less total memory, only six DIMMs to eight for the other systems, and a much lower wattage PSU (which may be more efficient at these load levels). Still, one can't deny the efficiency of its 50W quad-core Xeons—and one can't help but wonder whether Intel made the right call in choosing FB-DIMMs for its mainstream server platform just as performance per watt was becoming perhaps the key metric for server evaluations.