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
Macro2 - Tuesday, August 10, 2004 - link
John the Ripper results are completely invalid.The source code contains Hand-tuned ASSEMBLY routines, some of which only get called if the CPU has the word "Intel" in the name!!!!!
(And others are optimized for the K6. LOL.)
Totally bogus.
See x86.S detect.c and best.sh in the source package.
These results are garbage-- this "test" should be removed from the article.
The architecture-detection code is also probably broken, even in the generic case.
-----------------------T
The big picture was that K Kubcki doesn't know jack about compiling software on Linux.
He wrote a bogus Makefile, penalizing the K8 by 50%
He ran "John the Ripper" without looking at the source code, and noting hand-tuned assembly routines which are only called if the CPU has the word "Intel" in the name. So that one's completely invalid.
On top of that, he miscopied an earlier database result, again, against the K8.
Then he formulated a bogus conclusion.
The average user is not running miscompiled, largely irrelevant software.
eiger - Tuesday, August 10, 2004 - link
hi all,
I am new to this forum. Seems like an interesting
debate. I am in the scientific computing business
and over the past week I tried to benchmark the
existing processors we have here to get a bearing
on whether we should get the 3.4 GHz Xeon EM64T's or the opteron 248's for our new cluster (the prices seem to compare).
My numerical code which is
floating point intensive took about 6.60 seconds
using the intel fortran compiler on an Intel Xeon 3.06 GHz, while it took 3.98 seconds with the
portland groups fortran compiler (pgf90) on an opteron 246. Both were run 32-bit right now.
Moving to 64-bit on the opteron improved the
time by 0.2 seconds. Unfortunately I have no
access to a 64-bit Xeon yet.
Now using the intel fortran compiler gave 7.1s on the opteron and using pgf90 on the Xeon gave
6.90s. So it seems like the opterons can still
do better overall. pgf90 is versatile and can
optimize for both processors well.
Both machines have 2G RAM and 1 MB
L2 cache.
These are the highest end opteron and Xeon's I have access to at this moment.
I would love to hear your comments and suggestions
-j
eiger - Tuesday, August 10, 2004 - link
johnsonx - Tuesday, August 10, 2004 - link
To avoid further misunderstanding, my statement from the last post:"I'm not arguing that an A64 isn't generally faster than a P4."
Means that I agree that an A64 is generally faster than a P4.
johnsonx - Tuesday, August 10, 2004 - link
JGunther,Sorry, your post is irrelavant to this discussion. Since the AT article in question is strictly about 64-bit mode, some other article comparing a regular 32-bit 3.6Ghz to A64 running 32-bit apps is irrelavant. I'm not arguing that an A64 isn't generally faster than a P4.
Secondly, why are people here not grasping the FACT that a 3.6Ghz XEON EM64T and a Pentium 4 3.6F are the SAME for all practical purposes?
It's not "justifying", it's stating a fact.
JGunther - Tuesday, August 10, 2004 - link
johnsonx,Go read the comparison of an actual 3.6GHz P4 (not 3.6f, but who cares) vs. the s939 offerings.
http://www.aceshardware.com/read.jsp?id=65000316
AT did not just commit an act of bad journalism by comparing a server part to a desktop part, but as the numbers from Ace's Hardware review, AT's procedures are so bad and misrepresentitive, that it's downright fradulent.
You can justify the comparison of the Xeon and the A64 all you want. It's a moot point though, since AT's results are so incredibly flawed.
johnsonx - Tuesday, August 10, 2004 - link
To WiZzACkR,No sorry, you're still not making sense.
If a $850 Intel server part and a $400 Intel desktop part are the same (just one is pinned and validated for DP use), then having the $850 server part 'stand-in' for the as yet unavailable $400 desktop part doesn't invalidate the comparison to a $350 AMD desktop part.
To suggest an analogous situation, imagine AMD announced 2.6Ghz FX-55's and Opteron 152/252/852's. For sake of arguement, let's say pricing was $800 for the FX-55 and 152, $1000 for the 252, and $2200 for the 852 (no, I don't know if this is reasonable, but 8xx opterons are very expensive). Now, for whatever reasons AMD releases the Opterons ahead of the FX-55's, and AnandTech gets 4 852's for a server test. In another article, they use a single 852 to stand in for the soon to be available FX-55 and compare it to the currently available regular A64's, P4's and P4EE's.
In that situation, would be make any sense to complain that a $2200 server chip was being compared to much cheaper desktop chips? No, of course not. It doesn't make any sense now either.
An the desktop applications vs. server applications arguement is similarly pointless. Since the chips are the same, they run the apps the same.
Remember again, this was a general preview of Intel's EM64T running a commercial desktop Linux distro.
JGunther - Tuesday, August 10, 2004 - link
I personally would still like to know why this Nocona that they "got their hands on" is located in a server "in a remote location". What does this mean exactly?Anemone - Tuesday, August 10, 2004 - link
"I'm sorry Jim, I'm a doctor not a miracle worker! I'm truly sorry, but it's dead, there is nothing more anyone can do."*hands the next person the baseball bat*
Anyone else feel utterly compelled to beat this horse further?
Zebo - Tuesday, August 10, 2004 - link
KKWhy did'nt you say in your conclusion... "the Midrange A64 desktop chip. costing $500 less, absolutly destroys intel's best 64 bit offering in all real world tests"
hmmmm...
Instead you focus on synthetics, screw them up, and draw inflamitory conclusion. Come on, be fair.