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
snorre - Wednesday, August 11, 2004 - link
#194:eiger, I think the Opteron will be best overall in scientific computing compared to the Xeon EM64T, thanks to Opteron's built-in memory controller and point-to-point HyperTransport bus. I suggest you read this great review too for more numbers:
http://www.aceshardware.com/read.jsp?id=60000275
lewchenko - Wednesday, August 11, 2004 - link
So the original article had some flaws. OK accepted. They were spotted by the user community really quickly, and the staff at AT are dealing with them.
So all the people still going on about the original review, paid for by intel etc - Whats with the angst ? Grow Up, wait for the updated version with the Opteron's etc and stop whining. Anyone would think these people pay AT a fee for reading their work.
Just be thankful that these guys listen to your comments and do something about them. And for most of you making the noise still - I would like to see you do any better. How about it muddocktor ? (Comment 222)
Xspringe - Wednesday, August 11, 2004 - link
Come on everyone, let's keep things civil in here :)No need for personal attacks.
muddocktor - Wednesday, August 11, 2004 - link
Hi Kristopher,When did Anandtech hire you from Tom's Intel butt-kissing site? Your review really disappoints me in that it doesn't even come close to the articles and reviews I'm used to seeing here at Anandtech. If you want to do a comparison, please do it with processors that are in the same class at least. Your review tells me nothing substantial at all except that maybe you took some money from Intel for this pile of garbage.
chainbolt - Wednesday, August 11, 2004 - link
chainbolt - Wednesday, August 11, 2004 - link
I guess you did not understand the intenton of this article in the first place?allnighter - Wednesday, August 11, 2004 - link
I am looking forward to a new article. I'm also very glad Kris stepped in with some more feedback. Thank you.DerekWilson - Wednesday, August 11, 2004 - link
#217Much of what you've asked for/stated has been dealt with or will be dealt with in the upcoming article.
The implimentation of x86-64 is as different between AMD and Intel as each implimentation of x86. Just because they both support the same 64bit extensions doesn't mean code optimized for one architecture will lend itself well to the other (as each is better at different things).
I don't think integer performance is an open and shut case for Intel here. Remember that Intel has 2x 32bit ALUs inside the P4F, so integer performance under 64bit mode isn't a straight forward translation of 32bit mode.
Derek Wilson
ThePlagiarmaster - Wednesday, August 11, 2004 - link
All I want to see (besides that article being killed as completely misleading), is the use of REAL apps/games. NO synthetics. You drew conclusions PURELY based on synthetic scores (did your damage, slashdotted etc now). The complete opposite of a normal review. Most reviews tell you take the synthetics with a grain of salt, and look at the real apps/games tested. I don't care if you get the makefile/scripts or whatever correct. I don't want to see a review on synthetics at all (done right or not). If we haven't heard of the benchmark/game/app don't use it. I only recognized Povray in this review, which you dogged anyway. But at least its a REAL app that you CAN use to get work done (nobody does this..but it is REAL - rather see 3dsmax, Maya, Lightwave etc..)If Intel's integer unit is so good, it should show the same in 32bit. It's not just some 64bit Integer addon that only works in 64bit is it? We know A64 smokes in math (FP and INT). So prove it's not just some BAD SYNTHETIC benchmark showing us BS numbers. Run a 32bit REAL app that tests integer "that we all know about" and show it "THRASHING" the A64. There's nothing magic here, just your chosen out of this world benchmarks that we've never heard of. MS said AMD's 64bit is better than Intel's (the guy was LOL in fact in the interview over Intel's implementation), Andreas Stiller's source (CT magazine) came to the same conclusions (it's a software emu hack). So how is it you come up with these conclusions that it's magically great after we've been told it's REALLY CRAP? Intel's 64bit can't be better than AMD's when they copied AMD verbatim, and in doing so accidently got an "OLD DOCUMENTATION COPY" and ended up with emu crap (or so they say). Are the benchmarks above lying? I take it INTEL was very pissed about your Doom article (and the previous cpu article where athlon dominated also even in DIVX now), so they told you to run these OBSCURE benchmarks to save some face? Or you won't be receiving any new chips to test?
Take a look at these before your next review:
We see here in an old anand article 64bit shows around 15-20% (34% on Lame) improvement on A64:
http://www.anandtech.com/showdoc.aspx?i=1884&p...
Here's another, look at those encryption/Zip scores! What's that a 3x faster on RSA encrypt? It cut over 2/3rd's off the score.
http://www.xbitlabs.com/articles/cpu/display/athlo...
Another Encryption AMD vs. Intel (Itanium2 no doubt!):
http://www.itweek.co.uk/news/1142289
AMD 10% better than Intel Itanium 2! Dual vs. Dual.
Your own MySQL tests a good while back, where opterons crush Xeons repeatedly:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?...
Integer doesn't help MySQL AFAIK, so what magic made Intel so good? Also you better show some John The Ripper scores in 32bit, as IXBT shows us AMD get a 2-3x performance inscrease in most encryption stuff. I want to see if Intel did this too, otherwise this benchmark is crap. The benchmarks used here:
http://www.xbitlabs.com/articles/cpu/display/athlo...
ARE 64bit optimized (for A64), and shouldn't hurt Intel, as they are compatible now right? So in effect, they are optimized for X86-64 AND EMT64. Maybe you should be using those. Slight rehash of my previous post, but worth repeating in case Kris/Derek missed it. Check those benchmarks out on those sites please. Dump synthetics.
Macro2 - Wednesday, August 11, 2004 - link
RE:"What is wrong with my conclusion."What is wrong with John the Ripper?...that's what you must ask.
I figure you're going to learn a lot from this...
about phunny lines of code in benchmarks etc.
I've never seen a P4 core trounce a A64 in math like that..a light should have gone on is someones head.