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
kresek - Thursday, August 12, 2004 - link
Kris, how about the OpenSSL benchmark?Among others, RSA, DSA and AES-128 show nice performance boosts for AMD64, so it would be interesting to see how a EM64T capable chip performs in 32/64 bit modes.
BTW it does not take much time to complete ;)
JGunther - Thursday, August 12, 2004 - link
It's now past noon in half the country. :(splice - Thursday, August 12, 2004 - link
#261What the hell are you talking about? A free review? What site makes you pay to see there review of hardware? Don't forget Anandtech is partly, if not mostly, funded by it's readers and forum members! Ever notice those banner/dealtime ads and forums ads?
Kris' review was sloppy and skewed. He needs to make it right. He owes it to his readers and his boss! Otherwise, it's going to look like Anandtech could care less about what it publishes.
nastyemu25 - Thursday, August 12, 2004 - link
The message is clear: it's noon.Aileur - Thursday, August 12, 2004 - link
Its crazy how ungrateful you all are, he spends time on his vacation to please all of you whiners and all of you are complaining your free review isnt on time to the second.KristopherKubicki - Thursday, August 12, 2004 - link
The review is finished, I cannot post it until Noon though because we had another review go live instead. I am just about to get on the plane to go home anyway. Just wait a few more hours.Kristopher
offtangent - Thursday, August 12, 2004 - link
Ok, its been a lot more than 24 hours now ... is an actual report expected any time soon?snorre - Thursday, August 12, 2004 - link
Still no new review?!Kristopher: You should've also tested ApacheBench as well as compile times for the Linux kernal.
A proper review should at least compare 32-bit vs. 64-bit and 64-bit vs. 64-bit performance for both the Xeon 3.6GHz EM64T and Opteron 150 AMD64 processors.
gnuorder - Thursday, August 12, 2004 - link
This review is so poor, I'm sure it's not an attempt to skew the results. It looks to me to be a rushed review and a lack of understanding of the platform on which the testing was done.First you have the CPU selection. A server CPU that is not in hand as a stand in for a CPU that hasn't been released yet vs a chip that has been around and is most likely at it's EOL. This wouldn't be a problem for me if we are constantly reminded of this fact and no conclusions are drawn.
Second, The tests are done on a linux platform, which supports 64 bit but has to be tuned for 64 bit. It's a fair platform since 64 bit windows isn't ready but you have to know what you are doing. I think this was new to the author.
Third, tests should be selected carefully to either try and isolate certain aspects of each CPU or try and broadly select all aspects of the CPUs evenly. knowing what the test is actually doing helps out a lot. To the author's credit, he has source code and his binaries available for others to use. I dont think he knew what his various tests were doing, though, so conclusions based on them were meaningless.
Fourth, optimize for each platform or find a common optimization to test on. People are interested in both. Some will run off the shelf software that will be compiled to run on both, others will run software they can tweak for one CPU or the other and would be interested in seeing how far either CPU can be tweaked. What you can't do is run a test on both when it's tweaked for one and not the other. Again, I dont think the author knew how to tweak it, thus his confussion over the compile error he got.
One other note to those who think people are whining only because AMD lost, There have been many fair reviews pitting Intel vs AMD where AMD has lost and you didn't get this kind of response.
I don't think this review was meant to be a head to head test but it does have serious flaws that can't just be addressed by changing a few of the results. I think the article should be pulled and the tests re-done. This time don't rush through it to get it done before a vacation. We can all wait for a thoughtful review that gives us deep insight. This one does us no good.
Since the review is on a new mid-range desktop CPU, compare 2 new mid-range desktop CPUs on desktop motherboards with other mid-range desktop hardware. You can also throw in other CPUs and run 32bit vs 64bit tests as well but at least have 2 pretty well matched systems, and both in your control. Since it is desktop, run some typical desktop benchmarks along with your speciallized synthetic tests.
You serve the desktop users (gamers) better if they know how well doom3 or their favorite app is going to run on CPU x and how they can tweak it to run better. Using mathmatic or database tests on what is to be a desktop CPU on the desktop server is meaningless especially since you have a server platform as a stand in for one CPU.
Well I'm trying to end this but I keep thinking of more flaws to comment on and it's turning into another rant. It is just an awful review but let's give the author a chance to redeem himself.
cdo - Thursday, August 12, 2004 - link