Linux Shootout: Opteron 150 vs. Xeon 3.6GHz Nocona

danalien writes "Anandtech with their previous review have stirred up a bit of controversy, and they've released their follow-up review where they pit AMD's Opteron 150 vs Intel's Xeon 3.6 Nocona (on linux)."

Comments

Memory

[lachlan76]

To be able to show the real potential of the Opteron, you need to have more than one processor.

This lets you take advantage of the on-die memory controller, by letting each processor do it's own memory work, rather than making the Northbrige do all the work.

If you want to use a single processor, you might as well use an FX-Whatever, since they are just an Opteron without MP capability and only one HT bus.

Re:Memory

[ottffssent]

Actually, even without a NUMA-aware OS, the worst-case dual (and almost quad) memory latency is less than a Xeon's.

What really sets the Opteron apart in MP scenarios is the bandwidth. Each chip gets 6.4G/sec to memory: add more chips, get more bandwidth. The Xeon on the other hand has to share its 6.4G/sec with all the chips in the system, which severely limits its scaling. A quad Opteron has over 25G/sec of aggregate memory bandwidth, while a quad Xeon is stuck with its 6.4G shared 4 ways. That's half the bandwidth of a 400MHz P4 - no wonder the quad Xeons are often barely faster than the duals.

Add to this that cache snoops and other bus traffic all have to share the same FSB on the Xeon whereas on the Opteron local memory accesses don't touch the HT links at all. For a standard 2P system, this frees up 3.2G/sec of HT link bandwidth, and a NUMA-aware OS only increases the efficiency of the system.

Despite Intel's recent marketing push, they really don't have the best CPU, and don't have the best system either. There are still considerable advantages to choosing a Xeon system but these days they have little to do with the chip or the board and a lot to do with Intel backing. That's an advantage that will quickly evaporate as industry gets comfortable with non-Intel parts.

Difficult to trust?

[arose]

As we can see above, the difference between the two CPUs seems exaggerated and difficult to trust.

Maybe it's because Intel still makes processors for MHz and not performance? Maybe because unlike some comercial vendors the POV-Ray Team doesn't feel the need to make processor specific optimizations and leave that to job to the compiler (where it belongs)?

Re:Difficult to trust?

[ezzzD55J]

This review struck me as a bit clueless, or unfinished. The above quote is a good example of why i think so. They do some measurements, but aren't sure they're doing it fairly (compiler flags), and don't know what to do with the results. There is little in the way of analysis or conclusions. With the openssl measurements they don't even give any conclusions. But analysis and conclusions are the whole point of the review, and a remark like "As we can see above, the difference between the two CPUs seems exaggerated and difficult to trust." really devaluates this review - they're just showing us measurements they're not sure are correct ('difficult to trust') and let us figure out what they're worth?

Well, the conclusion that the opteron kicks the xeon's ass is pretty inescapable to me, finding out opteron is available and the xeon isn't quite yet and more expensive, really closes the deal to me. But the review isn't very scientific, and didn't go very deep.

Re:Difficult to trust?

[alienw]

That's because it is nearly impossible to do a scientific comparison of two different processors. Anyone who tells you otherwise is a moron.

You have to evaluate performance (possibly vs price) for your particular application. If you need a faster processor for Doom 3, look at Doom 3 benchmarks. If you need to encode video, look at video benchmarks. If you need to do integer computations, look at integer benchmarks. Xeons probably kick AMD's ass at some applications, and AMD might beat the Xeon at others. You can't just say that one is "better" than the other in general.

Re:Opteron cpu hacked

[Ianoo]

Microcode updates aren't permanent though - you need to reload them every time the machine boots. So clearly you would need to reload these "hacks" using a piece of software during the boot process.

Also, the article admits that it's "very unlikely" that a particular processor could be fried using a dodgy microcode update, so why even mention it? It would be much easier to write a BIOS flashing virus, I believe a few of these did exist at one point (although the old memory is failing). I doubt the hoops you'd need to jump through to write such a thing for Intel processors are no higher than for AMD processors, and as such, this is just FUD.

Hyperthreading is not good for these benchmarks

[DJStealth]

As hyperthreading cuts the L2 cache in HALF, it should be disabled before doing any of these benchmarks. Hyperthreading only seems to improve the multithreading ability. These benchmarks being run on a single process are not realistic.

Re:Opteron cpu hacked

[Sunspire]

I'm not sure if other Linux distributions do this already, but at least Fedora Core 1 and 2 both come with a processor microcode update service that runs in the bootup sequence. It's even enabled by default out of the box.

Linux has for a long time already mostly ignored the system BIOS since they're notoriously broken because of legacy reasons. Supplying known good microcode is simply another step in eliminating variables that make system testing needlessly complex, I predict we'll see more developments along these lines in general.