Linux and EM64T; Intel's 64-bit Suggestion
by Kristopher Kubicki on August 9, 2004 12:05 AM EST- Posted in
- Linux
Since the excuse to not compare Athlon 64s to Intel Pentium based processors has always been "you can't compare apples to oranges," we found ourselves fairly entertained to come into the possession of a 3.6GHz EM64T Xeon processor. Intel's EM64T is Intel's true x86_64 initiative. This 3.6GHz Xeon processor is actually the exact same CPU in as the LGA775 Pentium 4F we will see in just a few weeks. We are offering a preview of an unreleased processor on 64-bit Linux systems. Now, we have Intel and AMD 64-bit x86 processors, 64-bit Linux operating systems and a few days to get some benchmarking done.
We are going to run the benchmarks for this review slightly different than we have in the past. We want to make our numbers easily replicable for those who have the necessary components, but we also want to show the fullest capabilities of the hardware that we have. Many of our previous benchmarks are not multithread (POV-Ray) or do not scale well. Unfortunately, this forces us to use a lot of synthetic benchmarks; but we feel the overall results are accurate and reflective of the hardware used.
The delicate bit for this review was using the SuSE 9.1 Pro (x86_64) installation rather than compiling it from scratch (à la Gentoo). This was done to preserve the ability to replicate our benchmarks easily. Fedora Core 2 refused to install on the IA32e machine because there was no recognized AMD CPU.
As there may have been a little confusion from the last review, the DDR PC-3500 only runs at 400MHz. The Infineon Registered RDIMMs used on the Xeon runs at slightly high latencies. All memory runs in dual channel configurations. We removed 1 CPU for the tests in this benchmark, but since HyperThreading was enabled, we used the SMP kernel. During the second half of the benchmarks, SMP was disabled and the tests were re-run under the single CPU generic kernel. These are both 64-bit CPUs, and so, all benchmarks are run on 64-bit OSes with 64-bit binaries wherever possible.
We are going to run the benchmarks for this review slightly different than we have in the past. We want to make our numbers easily replicable for those who have the necessary components, but we also want to show the fullest capabilities of the hardware that we have. Many of our previous benchmarks are not multithread (POV-Ray) or do not scale well. Unfortunately, this forces us to use a lot of synthetic benchmarks; but we feel the overall results are accurate and reflective of the hardware used.
The delicate bit for this review was using the SuSE 9.1 Pro (x86_64) installation rather than compiling it from scratch (à la Gentoo). This was done to preserve the ability to replicate our benchmarks easily. Fedora Core 2 refused to install on the IA32e machine because there was no recognized AMD CPU.
Performance Test Configuration | |
Processor(s): | Athlon 64 3500+ (130nm, 2.2GHz, 512KB L2 Cache) Intel Xeon 3.6GHz (90nm, 1MB L2 Cache) |
RAM: | 2 x 512MB PC-3500 CL2 (400MHz) 2 x 512MB PC2-3200 CL3 (400MHz) Registered |
Memory Timings: | Default |
Hard Drives | Seagate 120GB 7200RPM IDE (8Mb buffer) |
Operating System(s): | SuSE 9.1 Professional (64 bit) Linux 2.6.4-52-default Linux 2.6.4-52-smp |
Compiler: | GCC 3.3.3 |
Motherboards: | NVIDIA NForce3 250 Reference Board SuperMicro Tumwater X6DA8-G2 (Only 1 CPU) |
As there may have been a little confusion from the last review, the DDR PC-3500 only runs at 400MHz. The Infineon Registered RDIMMs used on the Xeon runs at slightly high latencies. All memory runs in dual channel configurations. We removed 1 CPU for the tests in this benchmark, but since HyperThreading was enabled, we used the SMP kernel. During the second half of the benchmarks, SMP was disabled and the tests were re-run under the single CPU generic kernel. These are both 64-bit CPUs, and so, all benchmarks are run on 64-bit OSes with 64-bit binaries wherever possible.
275 Comments
View All Comments
tfranzese - Monday, August 9, 2004 - link
"The memory thing too.... if the benchmarks in question don't need more than 1Gb of ram, then why isn't 1Gb enough? Is there some magic of 64-bit systems where having 13267432Gb of RAM somehow makes them faster? Of course not."That was only mentioned by someone because much of the speculation has been that EM64T is no where near a match for AMD64 due to the reason being that AMD (and Apple, IBM) built a new architecture from the get go with this in mind to take advantage of a 64-bit world and Intel has simply bolted this to save face.
That said, part of the reasoning behind testing with more RAM is not to see if the performance improves but if it degrades despite not utilizing it.
JGunther - Monday, August 9, 2004 - link
Johnsonx, here's the deal. These numbers are bogus. This is such a miserable representation of any attempt at a comparison that people are going to kick and scream and find anything they can to blame it on. Server vs. Desktop, $350 vs. $800, 1MB cache vs. 512KB, poor benchmarking choices, poor benchmarking procedures, whatever the reason may be.It's one of them. It may be all of them. But you should know that people aren't whining because they compared a desktop chip to a server chip, but rather because this is a disgusting attempt at hardware review and comparison.
The staff of AT may get "rather tired of reading the uncivilized, juvenile" drivel on this page. All I can say is that the feeling is mutual.
johnsonx - Monday, August 9, 2004 - link
Just to be clear, my two rants were squarely directed at the whining complainers, not at those with reasonable issues to discuss regarding compiler config, merits of individual benchmarks, etc.That said, I still don't think the 3500+ vs. XEON arguement holds water. Yes, fine, an FX-53/Opteron x50 would be faster than a 3500+. So what? That's not the point of the article. It wouldn't be so much faster that any of the tests would have changed by much: tests that one CPU or the other dominated would still be dominated by almost unchanged margins and tests that were a virtual tie would still be a virtual tie.
The 'Server' vs. 'Desktop' CPU arguement is along the same lines, but put in those terms it is patently absurd. Apparently many folks out there think there is something somehow magic about 'Server' CPUs. Today, for both AMD and Intel, the only difference between desktop and server CPUs is the socket they fit in, the chipset they connect to, and whether they support SMP. Aside from a few special large-cache variants of the XEON (which we are not dealing with here), there is really no other difference. In fact, while at this time the effect is minimal or non-existant, at many times in the past 'Server' CPUs were often slower than their desktop counterparts. XEONs were stuck with 400Mhz or 533Mhz FSBs long after the desktop P4's moved to 800Mhz, Opterons originally launched with only PC-2700 support and still require slightly slower Registered ECC memory, AthlonMP's to this day are stuck with 266Mhz FSB and RAM as well as a much older, lower performing chipset. Now is the first time I can recall since the very end of the PIII days where a Desktop to 'Server' CPU comparison wouldn't actually give unfair advantage to the Desktop CPU. Today, it's as apples to apples as it gets.
The memory thing too.... if the benchmarks in question don't need more than 1Gb of ram, then why isn't 1Gb enough? Is there some magic of 64-bit systems where having 13267432Gb of RAM somehow makes them faster? Of course not.
I also get rather tired of reading the uncivilized, juvenile commentary from people who didn't even read the article carefully. I'm sure AT's staff does too.
For what it's worth, if you remember my post-script at the end of my original late night rant way back at comment 19, I really do have two Dual-Opteron servers sitting here ready to be delivered. Over the past 2+ years, I'd say I've purchased 100 Athlon TBirds and XP's, more than a dozen AthlonMP's, and now a half-dozen Opterons. In all that time, I've purchased maybe 3 Intel chips, all for upgrades of existing systems. So don't go assuming I'm pro-Intel or anti-AMD or whatever. I've made a business decision to use AMD, not a personal emotional one. I guess I do tend to make somewhat 'contrarian' choices in this regard; my ideal small business network is an AMD based server running NetWare & GroupWise, AMD based workstations running Windows XP Pro & Corel WordPerfect (and the GroupWise e-mail client, of course). Color me a rebel...
thpcgr - Monday, August 9, 2004 - link
This review sucks. I have a 2.8 nocona in an e7525 and it makes me feel even worse for having one. :-(And I can't even buy a peg 6800gt for it so I'm stuck with a diamond viper s550 pci for now!
Damn you intel!
Hurry up and come out with a dual opteron + dual peg platform!
thpcgr - Monday, August 9, 2004 - link
Roleplayer - Monday, August 9, 2004 - link
Did you perhaps leave off the Optimize -O2 which from what I've read elsewhere can as much as double the AMD64's performance? Without it, you're just optimizing the link, not the compiler.Marlin1975 - Monday, August 9, 2004 - link
http://www.theinquirer.net/?article=17754From listing...
""Relax, its just a primer for future articles. A 3.6F is supposed to compare with a "3600+" rated Athlon 64 isnt it? Since we dont have a 3600+ the 3500+ should perform slightly lower? Isnt this what we expected? And for those of you who dont believe me, a 3.6GHz 1MB EM64T Nocona is *exactly* like a 3.6F."
"I thought the AMD chip did pretty damn good for costing $500 less!"
Just a primer? Look at the concluding section’s second paragraph:
"Without a doubt, the 3.6GHz Xeon trounces over the Athlon 64 in math-intensive benchmarks. Intel came ahead in every severe benchmark that we could throw at it, particularly during John the Ripper. Even though John uses several different optimizations to generate hashes, in every case, the Athlon chip found itself at least 40% behind. Much of this is likely attributed to the additional math tweaking in the Prescott family core."
If the author had said that the "fastest 3.6GHz Xeon trounced the slowest socket 939 Athlon 64 in math-intensive benchmarks at $500 more in cost", that would have put the paragraph in context. But as it currently stands, someone at Intel Corp. will no doubt use the AnandTech quote for the chip giant’s next round of Xeon promotional material. Intel will be happy, if it understands "happy". µ"
vmajor - Monday, August 9, 2004 - link
To the deluded few, this review would be seen as a primer and would not be as offensive and would be given more slack IF it did not make such strong conclusions like these:"Without a doubt, the 3.6GHz Xeon trounces over the Athlon 64 in math-intensive benchmarks. Intel came ahead in every severe benchmark that we could throw at it, particularly during John the Ripper. Even though John uses several different optimizations to generate hashes, in every case, the Athlon chip found itself at least 40% behind. Much of this is likely attributed to the additional math tweaking in the Prescott family core."
If this 'review' was instead concluded with a disclaimer, and a 'to be continued', THEN it would be considered a primer.
As it is, this review is meritless, shoddy junk.
Pumpkinierre - Monday, August 9, 2004 - link
I thought the article was okay . As Kristopher states the Nocona is the same as the P4 3.6F in architecture and cache size which is approx. the equivalent of the 3500+ (remember the plus sign is supposed to mean something). As far as the tests go he's constrained by linux and the lack of 64 bit tests. If anything the OS and available tests will be AMD oriented due to Opterons/A64s having been out for the past year or so. If some of the test are 32bit coded it begs the question why the performance differences are so large for processors that are fully 32bit capable.Good on you Kristopher for an interesting article, keep on the 64bit trail we're all interested!
tfranzese - Monday, August 9, 2004 - link
"AnandTech has a right to compare any processor they wish. I don't care if they compared the Celeron to the Opteron, so long as the benchmarks and review were articulate and accurate. The cloudiness over what 'bit' some of the benchmarks were run at, the discrepancy between the benchmarks in the article and benchmarks from other sources (including AnandTech itself), and the errors and omissions are what really struck me about this article. "They certainly have the right, but people come here for fair, unbaised comparisons as they should expect from tech sites. People have grown to trust Anandtech and their judgements and then we have this. Not to long ago we also had their RAID 0 article which was real great at drawing conclusions on limited testing.