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
saechaka - Tuesday, August 10, 2004 - link
i don't know much about cpu but this thread has been a great read. to fifi, i don't think you thank the garbage man if he spews garbage on your driveway, but if he picks it up, you should. props to kris for picking up the garbage. maybgherald - Tuesday, August 10, 2004 - link
I think this article can be best characterized as "useless" or perhaps "how to not benchmark processors."I'm pretty sure Kris will take it as a lesson learned, and anticipate any follow ups will be more interesting/informative.
To those who allege Kris or Anand have somehow been paid by Intel: quit talking out of your ass. Seriously, I've got better things to do than read your senseless drivel.
People make mistakes, and that's all we should take away from this.
fifi - Tuesday, August 10, 2004 - link
I don't understand, what's with the thanking Kris ?Do you THANK your newspaper editor? do you THANK a TV news reporter? do you THANK your mailman?
This is his job, he is supposed to do it right. If he screws up, then he gets told off. That's all.
If he does a good job with it, then he is told that it's a job well done, more than that, AT gets visitors, gets sponsors and ads.
But he screws up major and we are supposed to THANK him for screwing up?
Do you THANK your garbage collector for spewing garbage all over your driveway? Do you thank your TV news reporter for giving you wrong *news*?
No, I am not grateful that this *review* was posted. It was incomplete, misleading, confusing and factually incorrect.
MikeEFix - Monday, August 9, 2004 - link
"Those who pay attention to our other articles should know the 3.6F and the 3500+ are in fact marketed against each other."This statement is incorrect
Viditor - Monday, August 9, 2004 - link
G'day Kris!Thanks for the reply! I can imagine that it's not easy to deal with all of the yammering...!
"I'll just remove all the 3500+ marks and you can all look back at my previous articles to see where this 3.6F stands"
PLEASE DON'T!!
If you could just post an Update saying that some possible errors occured and that you're looking into them, that would be much better...
"There was a problem with the MySql graphs. We posted the 32-bit marks on accident instead of the 64-bit"
I figured it was something like that...
"i'm open to retest and revise as many times as it takes to provid ethe best information i can"
Many thanks! That's all that most of the intelligent posters can ask for...please try to ignore the rest.
dtobias - Monday, August 9, 2004 - link
This article was either the perfect marketing gimmick for Anandtech.com, or a colossal screw up. This was like Coke saying they were pulling Coke Classic off the market. We'll know that it was nothing but a publicity stunt when Anand gets back from vacation and prints a retraction. If not, then we'll start looking for the new intel ads to pop up at Anandtel.com Hey - if they paid you then you have to put the ads up, right?plus - Monday, August 9, 2004 - link
Anand,Do the right thing. Take it down tonight, repost it when you believe it's accurate.
Don't be the next Tom's Hardware. Too many people count on Anandtech.com.
Plus
KristopherKubicki - Monday, August 9, 2004 - link
Alright.Heres the deal. I'll just remove all the 3500+ marks and you can all look back at my previous articles to see where this 3.6F stands.
Second, I asked if anyone wanted the binaries or test files from this review. I just went over my email and from the 120+ emails i got flaming me, 3 people asked for the binaries. I'm probably just going to give open shell access to the machine and let you guys find out for yourself where this machine stands.
There was a problem with the MySql graphs. We posted the 32-bit marks on accident instead of the 64-bit. The comments we posted on the benchmark magically still lined up.
DJB is one of my professors and i will discuss some of the issues raised with him concerning primegen. Thats if he doesnt cut my head off first for posting his program without his permission.
I need to persue the issues with TSCP. I'll admit, the only reasons i posted it here was because i saw it in Ace's benchmarks; whom i draw and extreme amount of respect from.
Regardless of what you may or may not think about the marks from the review, i'm open to retest and revise as many times as it takes to provid ethe best information i can. Simply stating "this review sucks" or "why did you compare these chips" without digesting the entire article has been extremely discouraging.
Oh and for all those people who think Intel paid me for this review or whatever; yeah right they dont even know i have their chips! Good luck trying to prove that one.
Kristopher
KristopherKubicki - Monday, August 9, 2004 - link
Testsnorre - Monday, August 9, 2004 - link
Slash dotted!http://linux.slashdot.org/linux/04/08/09/136230.sh...