Benchmarking: Titillating Results

Continued from 'Benchmarking a Quad-Core Beast'….

Now for the numbers. Intel provided pre-determined stats for the various programs we ran and encouraged us to correlate them with our results. As you'll see, the two sets of data are nearly identical:

Pretty much across the board, the quad-core system outran its dual-core predecessor, in spite of its core clock speed deficit. The majority of applications I ran yesterday were notably amenable to multi-threading optimization, and multi-tasking at the system level also lends itself to crafting a desired more-cores-is-better result. So your mileage may vary. But nonetheless….impressive. Particularly in the context of Paul Otellini's boast earlier in the week that his company would ship a million quad-core CPUs before AMD shipped its first quad-core Athlon.

The notable deviation from the overall trend was PCMark 05's 'Overall' test. As its name implies, it exercises all of the PC's primary subsystems, while 'CPU' focuses only on the microprocessor. Why, if PCMark's 'CPU' test favoured the quad-core CPU, did 'Overall' give the nod to the dual-core configuration? I have three theories, any or all of which may have factored into the results I saw:

1) 'Overall's' tests aren't heavily threaded/multi-tasking and therefore handicap a CPU with more cores in comparison to one with a higher core clock speed.

2) The four cores, all contending for front-side bus attention, may occasionally cause the bandwidth 'starvation' that I alluded to in my earlier writeup, and

3) Recall that the Hyper-Threading feature of past Intel CPUs didn't work well with threaded or multi-tasked code that contained predominantly floating point or integer (the more common scenario) instructions, due to contention overhead between the two 'virtual' cores for the same physical resources. This time around we're dealing with multiple physical cores, so the past problem isn't a factor, but a conceptually similar scenario may be at play. The 8 MBytes of total cache memory on Kentsfield is split between two physical die, which communicate with each other over the FSB; each die contains two physical cores, which share 4 MBytes of L2. Francois Piednoel, one of the Intel spokespersons present during my testing yesterday, indicated that the company strongly recommended its software partners not permanently lock a particular code thread to a particular core, because doing so would make the algorithms less portable to future, even higher core-count CPUs. However, by moving a thread around from core to core over time, you reduce the effectiveness of that thread's code and data stored in any particular core's cache allocation.

I'll be getting my own Kentsfield system 'soon' (can't say when exactly, due to NDA muzzles) and will be able to share my results with you 'soon' (ditto) afterwards. Rest assured that I'll throw a diverse set of software at the box and, in the process, will attempt to get to the bottom of the PCMark 05 results I obtained yesterday. Until then, I welcome your thoughts and suggestions.

Followup: Not surprisingly, AnandTech and ExtremeTech were among the 'chosen'. ExtremeTech was able to snag the screenshots that limited time precluded me from obtaining, and they've also got theories on why the quad-core PCMark 05 Overall scores were underwhelming. Check out both sites' writeups, along with ExtremeTech's bullish follow-up.