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
DerekWilson - Tuesday, August 10, 2004 - link
#213:It is much easier for other members of the AnandTech staff to setup Linux boxes comprised of the hardware Kris wants to test than for us to ship everything to him, have him work on it, then ship it back -- the AT staff is global, and the fact that SSH allows us this freedom is invaluable in Linux testing.
A "remote location" will always be with another AT staff member unless very specifically noted (though we would not be comfortable taking someone elses word on the system without having physical access to it).
Derek Wilson
prd00 - Tuesday, August 10, 2004 - link
I read all those comments, and some are nasty.. I think Kris is not providing thie valid benchmark suite, perhaps he doesn't know any optimization or anything inside there..I suggest, next time you provide benchmark that has proven to take advantage of both sides. Aces' Hardware comparison of server benchmark is a good example. Take a look at that..
About those fans that asking to compare against Opteron, I guess the figure will not so much difference, looking at some similarities between 3500+ and Opteron 150, or, should I say FX53 and 150, but I guess moving to FX53 will change the result a little. Remember P4 vs P4EE? Nocona is in P4EE position, while 3.6F is in P4 position. There is no way 3.6F is comparable in term of performance to Nocona. You forget about all Xeon having a huge L3 cache which help them tremendously here. But number that much difference are not supposed to change with move to Opteron 150. Granted, it will lessen the pain but Opteron is always on par with Xeon on single CPU config, some better, some worse. And with this new CPU, Opteron is supposed to be a little slower. But where Opteron really shines is when you put them into multi processor config which is normal on server system on which Nocona intended.
Well.. Kris, I'm waiting.. The only valid bench you provide are MySQL, GZip and Lame which is I know that it is 64 bit indeed. I can't consider your review is valid right now.
I suggest you void this review, and start a new review on real 64 bit vs 64 bit, in server environment vs server environment, and in server configuration vs server configuration. Dual Nocona vs Dual Opt and Quad Nocona vs Quad Opt will be good review. John the ripper is useless on server, and so does lame and SuperPI. We are talking about server CPU, so put server benchmark there. A real time database throughput, a request response, page per second, java performance, and so on. If you need reference, please look at this. This is the way server CPU comparison supposed to be done.
http://www.aceshardware.com/read.jsp?id=60000275
JGunther - Tuesday, August 10, 2004 - link
Kris, could you address comment #135?Basically, why is this Nocona located in a server "in a remote location". What does this mean exactly?
love4ever - Tuesday, August 10, 2004 - link
KristopherKubicki im sorry for all that coments, that are against you.i suport you, and your page.
good work.
thatsright - Tuesday, August 10, 2004 - link
For all the Bitching everyone here has done (including I), at least we have to give it to AnandTech and Kris for listening to it's audience and bending over backward in an effort to rectify the 'problem.'At least Kris K is address our complaints. Whens the last time you ever heard of Tom Pabst doing the same with one of his 'articles' on Tom's? While the overall nature of the article I read on AT was deeply troubling for it's incompleteness, its the only time I have really seen on AT. The same can't be said of Tom's Hardware guide.
Now stop whining, you bastards! It's not like were paying for these Articles. Just regard the article as a mistake, and save your whining for the Update.
LONG LIVE AnandTech.com!!!
tfranzese - Tuesday, August 10, 2004 - link
Glad to hear it Kris.KristopherKubicki - Tuesday, August 10, 2004 - link
I understand your concern for the other benchmarks, and the conclusions i drew were from those benchmarks. This is why we are doing another review as we speak. I hope the other article with more thorough realworld benchmarks makes more sense (should go live soon).Thanks,
Kristopher
tfranzese - Tuesday, August 10, 2004 - link
I've grown to ignore things like Sandra benchmarks and I guess I find it difficult to ignore these because even though you state these are synthetic the conclusion just puts a lot of weight into the 'victory'.tfranzese - Tuesday, August 10, 2004 - link
Okay, are you confident your other results are just as accurate? I only ask because John the Ripper, primegen, and ubench have also been mentioned in earlier posts. Not only in possible botched compiling, but perhaps their legitimacy as a valid benchmark - synthetic or not.KristopherKubicki - Tuesday, August 10, 2004 - link
TSCP and the incorrectly copied numbers for MySQL have been changed as stated earlier.Kristopher