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
kresek - Thursday, August 12, 2004 - link
Kris, how about the OpenSSL benchmark?Among others, RSA, DSA and AES-128 show nice performance boosts for AMD64, so it would be interesting to see how a EM64T capable chip performs in 32/64 bit modes.
BTW it does not take much time to complete ;)
JGunther - Thursday, August 12, 2004 - link
It's now past noon in half the country. :(splice - Thursday, August 12, 2004 - link
#261What the hell are you talking about? A free review? What site makes you pay to see there review of hardware? Don't forget Anandtech is partly, if not mostly, funded by it's readers and forum members! Ever notice those banner/dealtime ads and forums ads?
Kris' review was sloppy and skewed. He needs to make it right. He owes it to his readers and his boss! Otherwise, it's going to look like Anandtech could care less about what it publishes.
nastyemu25 - Thursday, August 12, 2004 - link
The message is clear: it's noon.Aileur - Thursday, August 12, 2004 - link
Its crazy how ungrateful you all are, he spends time on his vacation to please all of you whiners and all of you are complaining your free review isnt on time to the second.KristopherKubicki - Thursday, August 12, 2004 - link
The review is finished, I cannot post it until Noon though because we had another review go live instead. I am just about to get on the plane to go home anyway. Just wait a few more hours.Kristopher
offtangent - Thursday, August 12, 2004 - link
Ok, its been a lot more than 24 hours now ... is an actual report expected any time soon?snorre - Thursday, August 12, 2004 - link
Still no new review?!Kristopher: You should've also tested ApacheBench as well as compile times for the Linux kernal.
A proper review should at least compare 32-bit vs. 64-bit and 64-bit vs. 64-bit performance for both the Xeon 3.6GHz EM64T and Opteron 150 AMD64 processors.
gnuorder - Thursday, August 12, 2004 - link
This review is so poor, I'm sure it's not an attempt to skew the results. It looks to me to be a rushed review and a lack of understanding of the platform on which the testing was done.First you have the CPU selection. A server CPU that is not in hand as a stand in for a CPU that hasn't been released yet vs a chip that has been around and is most likely at it's EOL. This wouldn't be a problem for me if we are constantly reminded of this fact and no conclusions are drawn.
Second, The tests are done on a linux platform, which supports 64 bit but has to be tuned for 64 bit. It's a fair platform since 64 bit windows isn't ready but you have to know what you are doing. I think this was new to the author.
Third, tests should be selected carefully to either try and isolate certain aspects of each CPU or try and broadly select all aspects of the CPUs evenly. knowing what the test is actually doing helps out a lot. To the author's credit, he has source code and his binaries available for others to use. I dont think he knew what his various tests were doing, though, so conclusions based on them were meaningless.
Fourth, optimize for each platform or find a common optimization to test on. People are interested in both. Some will run off the shelf software that will be compiled to run on both, others will run software they can tweak for one CPU or the other and would be interested in seeing how far either CPU can be tweaked. What you can't do is run a test on both when it's tweaked for one and not the other. Again, I dont think the author knew how to tweak it, thus his confussion over the compile error he got.
One other note to those who think people are whining only because AMD lost, There have been many fair reviews pitting Intel vs AMD where AMD has lost and you didn't get this kind of response.
I don't think this review was meant to be a head to head test but it does have serious flaws that can't just be addressed by changing a few of the results. I think the article should be pulled and the tests re-done. This time don't rush through it to get it done before a vacation. We can all wait for a thoughtful review that gives us deep insight. This one does us no good.
Since the review is on a new mid-range desktop CPU, compare 2 new mid-range desktop CPUs on desktop motherboards with other mid-range desktop hardware. You can also throw in other CPUs and run 32bit vs 64bit tests as well but at least have 2 pretty well matched systems, and both in your control. Since it is desktop, run some typical desktop benchmarks along with your speciallized synthetic tests.
You serve the desktop users (gamers) better if they know how well doom3 or their favorite app is going to run on CPU x and how they can tweak it to run better. Using mathmatic or database tests on what is to be a desktop CPU on the desktop server is meaningless especially since you have a server platform as a stand in for one CPU.
Well I'm trying to end this but I keep thinking of more flaws to comment on and it's turning into another rant. It is just an awful review but let's give the author a chance to redeem himself.
cdo - Thursday, August 12, 2004 - link