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.
Facebook
Twitter
RSS
275 Comments
View All Comments
snorre - Wednesday, August 11, 2004 - link
#194:eiger, I think the Opteron will be best overall in scientific computing compared to the Xeon EM64T, thanks to Opteron's built-in memory controller and point-to-point HyperTransport bus. I suggest you read this great review too for more numbers:
http://www.aceshardware.com/read.jsp?id=60000275
lewchenko - Wednesday, August 11, 2004 - link
So the original article had some flaws. OK accepted. They were spotted by the user community really quickly, and the staff at AT are dealing with them.
So all the people still going on about the original review, paid for by intel etc - Whats with the angst ? Grow Up, wait for the updated version with the Opteron's etc and stop whining. Anyone would think these people pay AT a fee for reading their work.
Just be thankful that these guys listen to your comments and do something about them. And for most of you making the noise still - I would like to see you do any better. How about it muddocktor ? (Comment 222)
Xspringe - Wednesday, August 11, 2004 - link
Come on everyone, let's keep things civil in here :)No need for personal attacks.
muddocktor - Wednesday, August 11, 2004 - link
Hi Kristopher,When did Anandtech hire you from Tom's Intel butt-kissing site? Your review really disappoints me in that it doesn't even come close to the articles and reviews I'm used to seeing here at Anandtech. If you want to do a comparison, please do it with processors that are in the same class at least. Your review tells me nothing substantial at all except that maybe you took some money from Intel for this pile of garbage.
chainbolt - Wednesday, August 11, 2004 - link
chainbolt - Wednesday, August 11, 2004 - link
I guess you did not understand the intenton of this article in the first place?allnighter - Wednesday, August 11, 2004 - link
I am looking forward to a new article. I'm also very glad Kris stepped in with some more feedback. Thank you.DerekWilson - Wednesday, August 11, 2004 - link
#217Much of what you've asked for/stated has been dealt with or will be dealt with in the upcoming article.
The implimentation of x86-64 is as different between AMD and Intel as each implimentation of x86. Just because they both support the same 64bit extensions doesn't mean code optimized for one architecture will lend itself well to the other (as each is better at different things).
I don't think integer performance is an open and shut case for Intel here. Remember that Intel has 2x 32bit ALUs inside the P4F, so integer performance under 64bit mode isn't a straight forward translation of 32bit mode.
Derek Wilson
ThePlagiarmaster - Wednesday, August 11, 2004 - link
All I want to see (besides that article being killed as completely misleading), is the use of REAL apps/games. NO synthetics. You drew conclusions PURELY based on synthetic scores (did your damage, slashdotted etc now). The complete opposite of a normal review. Most reviews tell you take the synthetics with a grain of salt, and look at the real apps/games tested. I don't care if you get the makefile/scripts or whatever correct. I don't want to see a review on synthetics at all (done right or not). If we haven't heard of the benchmark/game/app don't use it. I only recognized Povray in this review, which you dogged anyway. But at least its a REAL app that you CAN use to get work done (nobody does this..but it is REAL - rather see 3dsmax, Maya, Lightwave etc..)If Intel's integer unit is so good, it should show the same in 32bit. It's not just some 64bit Integer addon that only works in 64bit is it? We know A64 smokes in math (FP and INT). So prove it's not just some BAD SYNTHETIC benchmark showing us BS numbers. Run a 32bit REAL app that tests integer "that we all know about" and show it "THRASHING" the A64. There's nothing magic here, just your chosen out of this world benchmarks that we've never heard of. MS said AMD's 64bit is better than Intel's (the guy was LOL in fact in the interview over Intel's implementation), Andreas Stiller's source (CT magazine) came to the same conclusions (it's a software emu hack). So how is it you come up with these conclusions that it's magically great after we've been told it's REALLY CRAP? Intel's 64bit can't be better than AMD's when they copied AMD verbatim, and in doing so accidently got an "OLD DOCUMENTATION COPY" and ended up with emu crap (or so they say). Are the benchmarks above lying? I take it INTEL was very pissed about your Doom article (and the previous cpu article where athlon dominated also even in DIVX now), so they told you to run these OBSCURE benchmarks to save some face? Or you won't be receiving any new chips to test?
Take a look at these before your next review:
We see here in an old anand article 64bit shows around 15-20% (34% on Lame) improvement on A64:
http://www.anandtech.com/showdoc.aspx?i=1884&p...
Here's another, look at those encryption/Zip scores! What's that a 3x faster on RSA encrypt? It cut over 2/3rd's off the score.
http://www.xbitlabs.com/articles/cpu/display/athlo...
Another Encryption AMD vs. Intel (Itanium2 no doubt!):
http://www.itweek.co.uk/news/1142289
AMD 10% better than Intel Itanium 2! Dual vs. Dual.
Your own MySQL tests a good while back, where opterons crush Xeons repeatedly:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?...
Integer doesn't help MySQL AFAIK, so what magic made Intel so good? Also you better show some John The Ripper scores in 32bit, as IXBT shows us AMD get a 2-3x performance inscrease in most encryption stuff. I want to see if Intel did this too, otherwise this benchmark is crap. The benchmarks used here:
http://www.xbitlabs.com/articles/cpu/display/athlo...
ARE 64bit optimized (for A64), and shouldn't hurt Intel, as they are compatible now right? So in effect, they are optimized for X86-64 AND EMT64. Maybe you should be using those. Slight rehash of my previous post, but worth repeating in case Kris/Derek missed it. Check those benchmarks out on those sites please. Dump synthetics.
Macro2 - Wednesday, August 11, 2004 - link
RE:"What is wrong with my conclusion."What is wrong with John the Ripper?...that's what you must ask.
I figure you're going to learn a lot from this...
about phunny lines of code in benchmarks etc.
I've never seen a P4 core trounce a A64 in math like that..a light should have gone on is someones head.