Linux and EM64T; Intel's 64-bit Suggestion
by Kristopher Kubicki on August 9, 2004 12:05 AM EST- Posted in
- Linux
Audio Encoding
Lame was compiled from source without optimizations. We only ran ./configure and make, without any flags. We realize that some people would like to verify our binaries and sample files for their own benchmarks. In order to save bandwidth and prevent copyright infractions, we will provide our test files and binaries under limited circumstances to serious inquiries. We ran lame on a 700MB .wav file using the command equivalent to the one below:# lame sample.wav -b 192 -m s -h >/dev/null
Encoding time, lower is better.
POV-RAY
Although POV-RAY is limited in application (particularly when compared against Mental Ray), it does provide a free open source solution for basic rendering. POV-Ray 3.50c was our choice of render engine for this benchmark. For benchmark specifics, we run the exact benchmark as specified by the POV-Ray official site. We use the precompiled RPM for this test.Render Time in Seconds, less is better.
POV-Ray does not have multithread support, so we were not surprised to see the HyperThreading configuration slowing down to the configuration without HT. We see the Athlon 64 processor pull way ahead; render tasks are extremely CPU and memory dependant. With the memory controller on the CPU, Athlon 64 becomes the stronger offering in this situation.
GZip
To throw in some rudimentary tests for GZip, we used the included GZip 1.3.5 to compress the .wav file from the benchmark above. We do not want to limit our I/O on writing to the hard drive, so the operation is performed as below:# time gzip -c sample.wav > /dev/null
Intel wins their first bout of the analysis, albeit not by much. We will find a recurring pattern later on with integer based calculations and the Nocona Xeon processor. The entire Prescott family of Intel CPUs received a dedicated integer multiplier rather than continually using the floating point multiplier. This becomes extremely useful in some of our other benchmarks.
Database Performance
We will run the standard SQL-bench suite included with RPM MySQL 4.0.20d.
Of all our benchmarks, the SQL-bench becomes the most baffling. The extremely threaded database application performs particularly poorly with HyperThreading enabled. The Althon 64 outperforms Intel again in this benchmark, and a lot of it is almost certainly accredited to the on die memory controller again.
Update: We copied the 32-bit marks from our benchmark in previous testing instead of the 64-bit. You can view the previous articles here from a month ago. The graphs have also been updated.
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.