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
Accord99 - Tuesday, August 10, 2004 - link
The hardware IOMMU is for devices that do not natively support 64-bit addressing, typically these are EIDE controllers, sound cards, USB controllers. So if you do a lot of I/O and have >4GB of memory you may see performance degradation. However, 64-bit SCSI cards, gigabit network controllers do support 64-bit addressing and the issue does not affect them at all. The latest SATA controller may also avoid the problem.And it is a chipset issue, not a CPU one. Intel could release a new chipset with a hardware IOMMU.
DrMrLordX - Tuesday, August 10, 2004 - link
That's cool. I'd like to see how the Opteron 150 does. Heck, even the 3800+ would be interesting. Either way, it'll be a good competition.xlax - Tuesday, August 10, 2004 - link
Not a big deal on the choice of hardware; it was just in there for reference anyway. Derek and I are working on an Opteron test as we speak. Gonna work some of the other little changes in the new review as well.Kristopher
hopefully some benchmarx.....and a lot less bs synthetix....
KristopherKubicki - Tuesday, August 10, 2004 - link
Not a big deal on the choice of hardware; it was just in there for reference anyway. Derek and I are working on an Opteron test as we speak. Gonna work some of the other little changes in the new review as well.Kristopher
DrMrLordX - Tuesday, August 10, 2004 - link
Agreed, the 3.6F P4 is not marketed against the 3500+. It's marketted against the 3800+.Kristopher, why are you so dismayed by people complaining about your choice in hardware? You picked the wrong AMD CPU. All the other flaws of your article aside, that flaw caught my eye first and affected my view of the entire article. The remarks in the conclusion clinched it.
I don't want you to think you're being "flamed" when I, or others, complain about the CPU comparison. If you want the AMD cpu poised to compete with the 3.6F, you want the 3800+, not the 3500+. If you want the competitor for the 3.6 Nocona, it's the Opteron 150/250/850. The competitor for the top-of-the-line EE cpu(which I believe is currently the 3.4, and will later be the 3.73) is the FX-53.
The 3500+ is the "cheap" CPU for socket 939 and nothing more.
xlax - Tuesday, August 10, 2004 - link
Hmmmmm, usually dont see this much action on ur reviews. Typically most of us like to see real benchies, not synthetics. Somebody get me a cold beer....thanx...anyways, we all know how sythetics can be optimized for a desired result. Lets see some real benchies. I usually like to read ur reviews cuz they have a balanced feel to them. This one smells.....I think maybe all these luv letters reflect the same and perhaps that is y u have been getting so much feedback. Pleased dont turn into THG, give us the real stuff, not the fluff.ps, synthetics dont mean @#!% to gamers and u know that.
Drayvn - Tuesday, August 10, 2004 - link
When i hear that the 3500+ is a good comparison to the 3.6f, i think that is wrong, in fact shouldnt it be that u should find what Intel are aiming the 3.6f at AMDs line.3500+ cant be very well compared to something that has come out after itself....
maybe the 3.6f was comparing itself to some other cheap maybe?
fifi - Tuesday, August 10, 2004 - link
what I objected to are sentiments such as"Again Thanks for the early release, it really and truly helped. I hope these fanboy's don't affect you decision to post early numbers in the future."
what did it "really and truly" help? creating more flame bait in a quiet neighbourhood?
if AMD is as much a litigious bast*rd like SCO (see SCO vs IBM/Red Hat/Novell/Daimler-Chrysler/Autozone) or Intel (see Intel vs 7intel and other tidbits with "intel" and "intel inside" trademarks) or Microsoft (see MS vs mikerowesoft.com), then they would be sending out CAD to AT for publishing bogus numbers, not to mention threats of libel and so on. And in this case, AT is not even in the right, eventhough it's clear it was just some mix up of the numbers (except that stupid conclusion...).
sure, if he ends up correcting it and does it properly, then he deserves the commendations. But it doesn't change the fact that it was screwed up in the first place, and to release numbers that looked strange even to a layman like me, without checking it thoroughly first is not a good thing for AT's reputation.
It just seemed like it was done in a hurry as if trying to rush out of the doors before anybody else does.
tfranzese - Tuesday, August 10, 2004 - link
Too little has been done to correct the matter to deserve much thanks IMO.fifi is spot on. There are times it's polite to say thank you for a job well done, but this isn't the time.
Viditor - Tuesday, August 10, 2004 - link
fifi - "But he screws up major and we are supposed to THANK him for screwing up?"No. We thank him for dealing with the inumerable flames over a mistake and being professional enough to correct them.
We also thank him because he works hard at this and probably gets paid substantially less than that garbage collector you alluded to!