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
DerekWilson - Tuesday, August 10, 2004 - link
#213:It is much easier for other members of the AnandTech staff to setup Linux boxes comprised of the hardware Kris wants to test than for us to ship everything to him, have him work on it, then ship it back -- the AT staff is global, and the fact that SSH allows us this freedom is invaluable in Linux testing.
A "remote location" will always be with another AT staff member unless very specifically noted (though we would not be comfortable taking someone elses word on the system without having physical access to it).
Derek Wilson
prd00 - Tuesday, August 10, 2004 - link
I read all those comments, and some are nasty.. I think Kris is not providing thie valid benchmark suite, perhaps he doesn't know any optimization or anything inside there..I suggest, next time you provide benchmark that has proven to take advantage of both sides. Aces' Hardware comparison of server benchmark is a good example. Take a look at that..
About those fans that asking to compare against Opteron, I guess the figure will not so much difference, looking at some similarities between 3500+ and Opteron 150, or, should I say FX53 and 150, but I guess moving to FX53 will change the result a little. Remember P4 vs P4EE? Nocona is in P4EE position, while 3.6F is in P4 position. There is no way 3.6F is comparable in term of performance to Nocona. You forget about all Xeon having a huge L3 cache which help them tremendously here. But number that much difference are not supposed to change with move to Opteron 150. Granted, it will lessen the pain but Opteron is always on par with Xeon on single CPU config, some better, some worse. And with this new CPU, Opteron is supposed to be a little slower. But where Opteron really shines is when you put them into multi processor config which is normal on server system on which Nocona intended.
Well.. Kris, I'm waiting.. The only valid bench you provide are MySQL, GZip and Lame which is I know that it is 64 bit indeed. I can't consider your review is valid right now.
I suggest you void this review, and start a new review on real 64 bit vs 64 bit, in server environment vs server environment, and in server configuration vs server configuration. Dual Nocona vs Dual Opt and Quad Nocona vs Quad Opt will be good review. John the ripper is useless on server, and so does lame and SuperPI. We are talking about server CPU, so put server benchmark there. A real time database throughput, a request response, page per second, java performance, and so on. If you need reference, please look at this. This is the way server CPU comparison supposed to be done.
http://www.aceshardware.com/read.jsp?id=60000275
JGunther - Tuesday, August 10, 2004 - link
Kris, could you address comment #135?Basically, why is this Nocona located in a server "in a remote location". What does this mean exactly?
love4ever - Tuesday, August 10, 2004 - link
KristopherKubicki im sorry for all that coments, that are against you.i suport you, and your page.
good work.
thatsright - Tuesday, August 10, 2004 - link
For all the Bitching everyone here has done (including I), at least we have to give it to AnandTech and Kris for listening to it's audience and bending over backward in an effort to rectify the 'problem.'At least Kris K is address our complaints. Whens the last time you ever heard of Tom Pabst doing the same with one of his 'articles' on Tom's? While the overall nature of the article I read on AT was deeply troubling for it's incompleteness, its the only time I have really seen on AT. The same can't be said of Tom's Hardware guide.
Now stop whining, you bastards! It's not like were paying for these Articles. Just regard the article as a mistake, and save your whining for the Update.
LONG LIVE AnandTech.com!!!
tfranzese - Tuesday, August 10, 2004 - link
Glad to hear it Kris.KristopherKubicki - Tuesday, August 10, 2004 - link
I understand your concern for the other benchmarks, and the conclusions i drew were from those benchmarks. This is why we are doing another review as we speak. I hope the other article with more thorough realworld benchmarks makes more sense (should go live soon).Thanks,
Kristopher
tfranzese - Tuesday, August 10, 2004 - link
I've grown to ignore things like Sandra benchmarks and I guess I find it difficult to ignore these because even though you state these are synthetic the conclusion just puts a lot of weight into the 'victory'.tfranzese - Tuesday, August 10, 2004 - link
Okay, are you confident your other results are just as accurate? I only ask because John the Ripper, primegen, and ubench have also been mentioned in earlier posts. Not only in possible botched compiling, but perhaps their legitimacy as a valid benchmark - synthetic or not.KristopherKubicki - Tuesday, August 10, 2004 - link
TSCP and the incorrectly copied numbers for MySQL have been changed as stated earlier.Kristopher