Another new addition for this review is, at long last, SPECpower_ssj2008. Like SPECjbb2005, this benchmark is based on multithreaded Java workloads and uses similar tuning parameters, but its workloads are somewhat different. SPECpower is also distinctive in that it measures power use at different load levels, stepping up from active idle to 100% utilization in 10% increments. The benchmark then reports power-performance ratios at each load level.
SPEC's run rules for this benchmark require the collection of ambient temperature, humidity, and altitude data, as well as power and performance, in order to prevent the gaming of the test. Per SPEC's recommendations, we used a separate system to act as the data collector. Attached to it were a Digi WatchPort/H temperature and humidity sensor and an Extech 380803 power meter. I should note that the Extech is not officially approved by SPEC. Although it generally works well enough, the Extech occasionally produces a clearly wrong reading, which is either approximately one half or twice the prior readingapparently a simple serial communications quirk. We've found that we can filter out these errors with a simple inspection of the data, and SPECpower appears to catch the errors, as well. Our results would not be accepted for publication by SPEC unless we used an approved (and much costlier) power meter. They should, however, be good enough for our purposes.
We used the same basic performance tuning and system setup parameters here that we did with SPECjbb2005, with the exception that we lowered the JVM heap size slightly to avoid a memory allocation error. Here's an example of the Java options from our Istanbul system:
-Xms3700m -Xmx3700m -Xns3000m -XXaggressive -Xlargepages:exitOnFailure=true -Xgc:genpar -XXgcthreads:6 -XXcallprofiling -XXtlasize:min=4k,preferred=1024k
Like I said, the heap size is the only real change. Due to this benchmark's long run times, we only ran it once on each system.
SPECpower_ssj results are a little more complicated to interpret than your average benchmark. We've plotted the output in several ways into order to help us understand it.
Here's a look at ssj_ops, the benchmark's measure of performance, and the power consumed in watts at each load level. The Istanbul Opteron 2435-based system looks awfully good here; its power consumption is similar to the Shanghai system at each load level, but with substantially higher performance. The Xeon X5550 system is a little different; at active idle, it draws 142W, versus 150W for the two Opteron boxes. Beyond that, the Xeon X5550 system draws more power but achieves higher performance at each step than the Opteron 2435.
A look at performance-to-power ratios should help clarify things.
Now we can see just how incredibly close a race this is. The performance-power curves for the Opteron 2435 and Xeon X5550 systems almost perfectly overlap, amazingly enough. The Nehalem Xeon is slightly superior at the lower load levels, but the Istanbul box takes a lead as utilization climbs to 40% and higher.
Obviously, Istanbul's showing here represents a solid advance over Shanghai. Multi-core processors tend to offer very strong power efficiency propositions with highly parallel workloads. Adding two more cores and dialing back clock speeds in order to fit into the same power envelopes as Shanghai proves to be a very effective strategy in this case.
Surprisingly, the Xeon X5550 system manages to out-point the Opteron 2435 in SPECpower_ssj2008's overall performance per watt summation, although only by an eyelash. The overall result takes power draw at active idle into account, which is probably what puts the Xeon over the top. Make no mistake, though: this Istanbul system is very much a match for the Xeon in terms of power-efficient performance.