January 2nd, 2008

A comparison of quad-core server CPUs

Posted by George Ou @ 3:52 pm

Categories: AMD, Energy efficiency - green, Hardware, Intel, Processors, Servers, Workstations

Tags: Processor, Quad-core, Memory Bandwidth, Server, Dual Processor, Advanced Micro Devices Inc., CPU, Intel Corp., Chip, TLB

For anyone looking to buy a workstation or server CPU, quad-core CPUs have become mainstream. Therefore it’s important to know what you’re getting for the money so I’ve compiled a chart with general purpose computing performance using the SPEC CPU database with the highest scores as of December 28, 2007. I included single and dual processor solutions to help you decide whether you want to go single CPU socket or dual socket motherboard. You and also read more about energy efficiency on server processors here.

Note: This information is also available as a PDF from the TechRepublic Downloads Library.

All Intel dual processor models starting with the 54xx are the latest “Harpertown” 45nm CPUs launched in November 2007. All Intel dual processor models starting with 53xx are the 65nm “Clovertown” quad-cores Intel launched in late 2006 and mid 2007. In the single processor space, only the QX9650 “Yorkfield” processor uses Intel’s latest 45nm process and everything else uses the 65nm process. The Q6600 and X3220 are essentially identical processors marketed towards desktop and entry level server markets respectively. Since one of the key differentiators on a workstation/server system is the inclusion of error correction memory, one can use any of the desktop CPUs in an ECC capable single processor motherboard.

The two AMD processors are Opteron quad-core CPUs based on 65nm “Barcelona”. The 2.0 GHz Opteron 2350 is delayed due to the TLB bug and the 2.5 GHz Opteron 2360SE won’t come out until the B3 stepping is out which fixes the TLB bug and brings higher clock speeds. There are reports that B3 stepping may be delayed until Q2 of 2008 (tranlated link here) though AMD’s last analyst meeting presentation has a rough timeline of Q1 or Q2.

Note: SPEC CPU is broken down by performance on general purpose integer and scientific memory-bandwidth/floating-point intensive workloads. The general purpose workloads are summarized by a geometric mean score called SPECint and the scientific workloads are summarized by a geometric mean score called SPECfp. The results are further broken down by single-threaded results and multi-threaded results labeled as “rate2006″. Note that a geometric mean is sort of like an average but it punishes the extremes more with a lower score than the average if a particular chip performs very poorly on some workloads. Ideally, one would simply benchmark their own specific application but that’s not always possible so these published numbers from SPEC are very valuable data points.

SPECint includes workloads like Perl, compression, compilers, video compression, and other general purpose workloads. SPECfp includes workloads like bwaves, gamess, gromacs, povray, and a dozen other memory bandwidth and floating point intensive benchmarks. So while it’s important to have a general ideal of how a chip performs in general, discriminating buyers will look inside the detailed disclosure (which I link to) and look at the application that is most similar to their own. So while a chip from AMD might have a lower overall score on SPECfp_rate2006, there are individual workloads within SPECfp that overwhelmingly favor AMD’s memory bandwidth advantage. The inverse of this situation where an Intel CPU has a lower overall SPECfp score than an AMD CPU but still win some of the specific workloads can also be true. So in a nutshell, the chip you select should be based on your application requirements.

* These results were invalidated last month because of lack of availability. Furthermore, the TLB bug patch performance penalty has not been factored in to these results. Assuming AMD fixes the bug in Stepping B3 and solves the manufacturing challenges in mid 2008 to deliver 2.5 GHz parts, scores similar to these invalidated numbers can be resubmitted. So while these numbers are officially invalidated, they were invalidated for lack of availability and not for inaccuracy so I left these numbers in for comparison purposes.

** Results for the X5482 3.2 GHz systems seem odd since they’re worse than the E5472 3 GHz results. Intel gave an unofficial estimate at IDF2007 of 89.8 for SPECfp_rate2006 so we might see this number get updated as time goes by. Note that the SPEC CPU base scores for the X5482 were higher than the E5472 so that seems to fall more in line with expectation.

These results indicate a significant improvement with Intel’s latest 45nm technology in multi-threaded applications. Comparing 3 GHz Harpertown with 3 GHz Clovertown, improvements for single-threaded applications were noticeable in the 8% range and that is mostly attributable to architectural enhancements in the chip’s execution engine. At 3.0 GHz for multi-threaded applications, we saw a ~14% improvement on both SPECint and SPECfp using the same motherboard chipset and the additional gains are mostly due to the 50% larger CPU cache. But once the new 5400 series “Seaburg” chipset got involved with a 50% larger snoop filter and 20% faster memory bus, the 3.0 GHz scores jumped 22.2% for SPECint and 30.1% for SPECfp.

Considering the fact that the energy efficient 45nm Intel E5410 2.33 GHz chip costs around $300 whereas the 65nm Intel E5345 2.33 GHz chip costs around $600, buyers who are looking for Intel based solutions should immediately switch to 45nm technology. The Intel E5410 even manages to beat the $1200 Intel X5365 3.0 GHz processor on SPECfp_rate2006 and comes awfully close on SPECint_rate2006. So for the general purpose server market, the new E5410 on average seems to be the performance/dollar leader.

HPC (High Performance Computing) customers who have memory bandwidth intensive workloads on the other hand have been purchasing loads of inexpensive AMD Barcelona processors despite the TLB bug. Those memory-bandwidth hungry customers are using custom Linux kernels that work around the TLB bug with minimal impact on performance so they don’t care about the bug or the lower overall SPECfp scores.