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
dke - Monday, August 9, 2004 - link
Hi, I just read this comparison betweenthe Xeon 3.6 (Nocona) and the Athlon 64 3500+. This is from an e-mail I sent out earlier today and I didn't want to re-write it again. Here it is:
"I started reading
AnandTech's article and noticed that on the third page they have a
little note that says:
"Our Nocona server was setup in a remote location with little access,
so we had limited time to run as many real world benchmarks as we are
typically accustomed to. Fortunately, there are multitudes of
synthetic benchmarks that we can use to deduce information quickly and
constructively."
This seems to contradict the statements they made in the first
paragraph of the first page of the review:
"... we found ourselves fairly entertained to come into the possession
of a 3.6GHz EM64T Xeon processor. ..."
What does that mean?
Unless I am not understanding this correctly, is sounds like
AnandTech's reviewers didn't have local access to the computer that
they were using to benchmark the Nocona. Does that mean that they
didn't have local access to the computer for [any] of their benchmarks,
or only the synthetic ones? If that's true, I don't think this can be
a trusted review. Who would setup a Nocona server for AnandTech to
"review"? Intel? I can see that...
Intel: "we equipped this machine with the following specs, xxxxxx. we
promise..."
Right.
This article just seems questionable to me, and I remain fairly
skeptical about how accurate this review/comparison is. If AnandTech
didn't have local access to the machine, how can anyone be certain
that the system's specs are what AnandTech claims they are? How can
AnandTech's reviewers themselves be certain? [The benchmarks given in this comparison do not duplicate previous benchmarks using the same hardware as well as the same benchmarking software.] It's not that I think
AnandTech is feeding us misinformation, but I question the information
given to them by this mysterious third party [who has local access to
the machine?]."
I just don't understand and I would like an official response from AnandTech. I don't care to hear Intel fangirls respond to my question. They don't know anything more than I do. I can read enough sarcasm and smart-arse comments on this board without any new sarcastic responses to this post.
Thank you.
David K.
ThunderPC - Monday, August 9, 2004 - link
Nice way to generate site hits by making the entire "techy" world come by for a good dose of laughter at the "comparison".Graphic67 - Monday, August 9, 2004 - link
Keep in mind that Mr. Kubicki is the "Senior Display, Optical Storage and Linux Editor" and from a listing of available articles he has not done a CPU review before.AnandTech had a reputation of quality over quantity (or speed) which made the articles that much more worthwhile to read. "Quick and dirty" as an earlier post called this review is a phrase which would normally not be applicable to an AnandTech posting.
ThunderPC - Monday, August 9, 2004 - link
Like everyone else has said, the worst review I have seen since boycotting Tom's hardware. I am completely unbiased on processor manufacturer, and have a relatively new Intel and AMD system. That being said, why the #$%( are we comparing these two processors? How much did Intel pay you to do such a lopsided test? I have a Kyro video card sitting in a box if you care to test it against a 6800 :Dsnorre - Monday, August 9, 2004 - link
This bad review really have created a big buzz. People are debating it heavily over at Ace's Hardware:http://www.aceshardware.com/forum?read=115093783
This review should never have been published, and if it dosen't get removed of fixed soon Anandtech will for ever lose its credibility and join the line of biased sites like Tom's Hardware & Extreme Tech.
Viditor - Monday, August 9, 2004 - link
johnsonx - "The memory thing too.... if the benchmarks in question don't need more than 1Gb of ram, then why isn't 1Gb enough? Is there some magic of 64-bit systems where having 13267432Gb of RAM somehow makes them faster? Of course not."A reasonable question...
The reason that memory is questioned is that the Nocona has no hardware IOMMU. This means that when using larger amounts of memory (3 Gig+), the Nocona (and all other EMT64 chips) will actually start to slow down.
schemer - Monday, August 9, 2004 - link
AnandTech! Did you try benchmarking KristopherKubicki against a Blonde?coldpower27 - Monday, August 9, 2004 - link
I believe benching the Opteron 150, would have been a fairer choice like I said.
I also don't beleive the 512KB of cache vs 1Mb of cache holds any water, because of the fact that the Netburst Prescott has to make due with 16KB of LV1 cache while the Athlon 64 gets 128KB of it which is 8 times more :S
I am also not all that sure if the Opteron 150 will be all that much faster then the Athlon 64 3500+ considering it has to work with registered memory and 600MHZ HT.
Comparing AMD's K8's and Intel Netburst Architecture has been always Apples to Oranges. you couldn't really compare Apples to Apples anyway with how different these 2 architectures are.
mkruer - Monday, August 9, 2004 - link
to add more flamebait, you got to love this quote"Since the excuse to not compare Athlon 64s to Intel Pentium based processors has always been "you can't compare apples to oranges,""
so now hes comparing oranges to apples.
Snoop - Monday, August 9, 2004 - link
Kristopher,Are you going to defend this article? It seems that your silence to these charges speaks for itself. If you cannot dispute these claims, then remove the article.