Linux and EM64T; Intel's 64-bit Suggestion
by Kristopher Kubicki on August 9, 2004 12:05 AM EST- Posted in
- Linux
Audio Encoding
Lame was compiled from source without optimizations. We only ran ./configure and make, without any flags. We realize that some people would like to verify our binaries and sample files for their own benchmarks. In order to save bandwidth and prevent copyright infractions, we will provide our test files and binaries under limited circumstances to serious inquiries. We ran lame on a 700MB .wav file using the command equivalent to the one below:# lame sample.wav -b 192 -m s -h >/dev/null
Encoding time, lower is better.
POV-RAY
Although POV-RAY is limited in application (particularly when compared against Mental Ray), it does provide a free open source solution for basic rendering. POV-Ray 3.50c was our choice of render engine for this benchmark. For benchmark specifics, we run the exact benchmark as specified by the POV-Ray official site. We use the precompiled RPM for this test.Render Time in Seconds, less is better.
POV-Ray does not have multithread support, so we were not surprised to see the HyperThreading configuration slowing down to the configuration without HT. We see the Athlon 64 processor pull way ahead; render tasks are extremely CPU and memory dependant. With the memory controller on the CPU, Athlon 64 becomes the stronger offering in this situation.
GZip
To throw in some rudimentary tests for GZip, we used the included GZip 1.3.5 to compress the .wav file from the benchmark above. We do not want to limit our I/O on writing to the hard drive, so the operation is performed as below:# time gzip -c sample.wav > /dev/null
Intel wins their first bout of the analysis, albeit not by much. We will find a recurring pattern later on with integer based calculations and the Nocona Xeon processor. The entire Prescott family of Intel CPUs received a dedicated integer multiplier rather than continually using the floating point multiplier. This becomes extremely useful in some of our other benchmarks.
Database Performance
We will run the standard SQL-bench suite included with RPM MySQL 4.0.20d.
Of all our benchmarks, the SQL-bench becomes the most baffling. The extremely threaded database application performs particularly poorly with HyperThreading enabled. The Althon 64 outperforms Intel again in this benchmark, and a lot of it is almost certainly accredited to the on die memory controller again.
Update: We copied the 32-bit marks from our benchmark in previous testing instead of the 64-bit. You can view the previous articles here from a month ago. The graphs have also been updated.
Facebook
Twitter
RSS
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.