Interesting results.. I’m hoping to play with the NAS benchmarks (and some personal codes) on an Intel Harpertown w/1600Mhz FSB over the next few days – it should help with the memory problems, even though it still does use an FSB.

As an aside, I believe your table rows are out of order in the fifth table. For example, bt and cg are in reverse order compared to the other tables, as are several other of the components. Just thought I’d let you know. Otherwise, thanks for the article!

– B

Another interesting comparison would have been a dual-socket Intel Woodcrest system vs. a dual-socket AMD SocketF system. This way you would have been comparing dual-core Intel to dual-core AMD in 4-way systems. In your tests, the Intel has a memory bandwidth handicap because it has four cores sharing a FSB while the AMD has only two cores sharing a memory controller. The better scaling of the AMD system shows this. I would love to see you repeat your test using AMD Barcelona processors when the clock speed is sufficient to compare to Clovertown. Thanks for an interesting article.

Jim

I’m not as convinced as you are that the kernel and core libraries don’t matter in the test, especially when dealing with scalability issues. There are three specific system characteristics that seem likely to affect processor scalability: memory “balance” (something that includes but is not limited to raw bandwidth in a multicore situation — the amount of parallel bandwidth available to the cores as they attempt to access chunks of memory moving through the CPU); kernel “balance” — how smoothly it distributes and manages resources required by the various processes (when they execute e.g. a malloc or use a system call of any sort, but also more subtle things like the synchronicity of process scheduling on the multiple cores); libraries (including libc, libm).

I can easily believe that the Opteron has better memory balance than the Intel, simply because it always has. I’m guessing that this is the primary source of the Opteron’s scaling advantage — hypertransport is a powerful and fairly scalable thing. However, it COULD be also related to how well the different cores effectively desynchronize their memory accesses, which in turn could be related to kernel/scheduler differences. I’d also be interested in knowing whether or not you have objective evidence that (all things being equal) changes in libc, libm, and any other library differences between RHEL 4 and FC 6 don’t lead to measurable differences in the performance of even flat numerical code.

Mind you again, I would expect that if anything the Intel results would be ADVANTAGED relative to the AMD results from running FC 6; RHEL 4 is more than a bit “tired” (and even FC 6 is aging fast, given that today is Fedora 8th’s “birthday”:-).

One last thing that might have been or would be of interest is a graph of performance scaling that factors in clock speed and maybe nominal (list price) cost. After all, at the end of the day it is the amount of work you get done per unit time per dollar spent that matters.

rgb