Intel 7500 Series "Nehalem-EX" Xeons
Posted on: 03/30/2010 10:57 PM

SPECjbb 2005 v1.07

SPECjbb2005 (Java Server Benchmark) is SPEC's benchmark for evaluating the performance of server side Java. Like its predecessor, SPECjbb2000, SPECjbb2005 evaluates the performance of server side Java by emulating a three-tier client/server system (with emphasis on the middle tier). The benchmark exercises the implementations of the JVM (Java Virtual Machine), JIT (Just-In-Time) compiler, garbage collection, threads and some aspects of the operating system. It also measures the performance of CPUs, caches, memory hierarchy and the scalability of shared memory processors (SMPs). SPECjbb2005 provides a new enhanced workload, implemented in a more object-oriented manner to reflect how real-world applications are designed and introduces new features such as XML processing and BigDecimal computations to make the benchmark a more realistic reflection of today's applications.SPECjbb2005 is a widely used, industry standard benchmark.

In a nutshell, each "warehouse" spawns an independant thread which determines the concurrency of the benchmark run. Systems tested have a an expected peak number of warehouses (X) that correspond to the total number of "hardware threads" in the machine. Scores are output as "Business Operations per Second (BOP/s)", and are based on average throughputs of X, X+1, X+2, X+3, etc, up to and including 2X.

I wasn't trying to set a SPECjbb record here. I just wanted to run the workload as a comparison of the two platforms being evaluated here. As such, I used Sun's 64bit JVM (JAVA 6 update 18 x64). I ran the tests with a single JVM and the following commandline options: -Xms3700m -Xmx3700m

Nehalem-EX SPECjbb

I've made a point of not trying to tune SPECjbb too much in the past as I try to present an "out-of-the-box" type experience with our workloads. I think my philosophy might have to change moving forward, because here we see the Nehalem-EX machine turning in some pretty stellar numbers but the results as the number of warehouses increase are all over the place.

I could have smoothed the line quite a bit by using a more robust JRE/JVM, running multiple instances of the JVM and tuning the commandline options for SPECjbb. To this point I haven't needed to do any of that to get good, comparative results, but I think my methods have hit their ceiling at 32 threads. 

x264 Bench 3.0 HD

The x264 benchmark is a reproducible measure of how fast your machine can encode a short, HD-quality video clip into a high quality x264 video file. The video encoder (x264.exe) reports a fairly accurate internal benchmark (in frames per second) for each pass of the video encode (Four two-pass encodes) and it also uses multi-core processors very efficiently. All these factors make this an ideal benchmark to compare different processors and systems to each other.

Nehalem-EX x264

The x264 benchmark scales pretty well on multi-threaded machines. That being said, it is not the most efficiently threaded workload. When watching Task Manager during this test it rarely ever peaks at more than 85% processor utilization, so the raw clock speed of those cores sometimes makes more of an impact than the number of cores (or threads) available. In this case the Opterons are a bit slower on the first pass of the encoding, but they more than make up for it on the second pass.

Final Thoughts

Taken in context, the Nehalem-EX platform is pretty impressive. While it doesn't offer the raw processor clock speeds of its Westmere-EP bretheren, it packs a large number of cores (and threads), the capability to address HUGE amounts of memory and a slew of reliability features into an affordable x86/64 server package. Features that were previously only available in big-iron boxes are, as of today, a reality for small and medium businesses, opening doors to all new possibilities for what is probably the largest sector of the server market.

With OEMs like Dell offering server solutions like the R810, the future is bright for the x86/64 server market. Itanium? Maybe not so much.

Printed from (,6.html)