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 - Monday, August 9, 2004 - link
I'm *VERY* disappointed with this review. Why on earth didn't you compare it with Opteron 150 or Athlon 64 FX-53? Useless! :(Anemone - Monday, August 9, 2004 - link
As others have commented, the cache probably would have altered these positions. It would have been easy to take an FX and trim the clock down to 2.2ghz if you wanted a close "claimed rating" comparison. It's not exactly a secret that cache helps servers, I mean since that was teh foundation for the entire Xeon line as different from the P4...I'm taking this in, as I haven't made my decision yet, but honestly there is so much evidence that this analysis falls counter so so many others that I think you have to start over, or at minimum throw a few chips in the mix to see if there was some variation, as well as showing us what the 32bit scores are. And you danced quite interestingly around 64bit Unreal scores which I'm pretty sure you have on hand as well.
What's amusing from all these comments is that you quite obviously have had these results for quite a while, as I know things don't get published entirely instantly, and yet knowing the results didn't change your system recommendations away from the A64's. So, that being true, show us a bit more, because I'll bet there is more to this than meets the eye.
Would also like to suggest in places where you throw up a bunch of cpu's if you would show an FX or one of the A64's at a slightly higher memory bandwidth as a standard item from now on. Most folks seem to be at minimum turning their machines to 225 memory vs 200, and I think that easy speed being possible for even the simple oc'er should show a result on the charts. If you want to be fair you can show the same, say 230-240fsb for P4's but I'm confident that won't really put them in any better light, though it would be fair.
Hope to see more thorough analysis soon!
j3pflynn - Monday, August 9, 2004 - link
What on earth was that CPU selection about?! Quite inappropriate? Is that the only way Intel would send you their latest?Carfax - Monday, August 9, 2004 - link
I joined AT just so I could post a comment on this review..The review is TERRIBLE! When I saw the heading, I thought FINALLY! We're going to see how good EMT64 is compared to AMD64.
Ofcourse, you can imagine how disappointed I was when I saw that you didn't even have any 32bit reference benchmarks for the Nocona..
Also, you used WAY too many synthetic benches. Like the other members, I'm suspicious of synthetic benches because they are a poor indicator of real world performance.. Also, I have to wonder what possessed you to include these particular benches, when AT didn't use them for the other 64bit benchmarks.
Not to mention, you should have atleast compared an FX to the Nocona, and not just an A64!
Shame on you!
mjz5 - Monday, August 9, 2004 - link
Wouldn’t it be fair to compare AMD's fastest CPU (3800+) with Intel’s fastest? They are at the same price level! You can't compare CPUs base on spec's allow, price is a bigger issue.srg - Monday, August 9, 2004 - link
*johnsonx*I wouldn't give up on those opterons yet. The reason why everyone else is flaming here is that it wasn't a fair test. They tested an top end Xeon with a mid range desktop CPU. It would be like compairing a top opteron with a P4 2GHz Northwood.
If it was between a top Xeon and a top opteron and the opteron still got stomped on, then there would be no need to flame (and no I don't agree that a 3600+ desktop CPU is compairable with a top end server CPU).
Although you moan about AMD worshippers, you do sound more like an Intel fanboy.
srg
fifi - Monday, August 9, 2004 - link
Hi Kristopher,There are some discrepancies:
for MySQL Test-select, you used the 32-bit result for A64 3500+, instead of the 64-bit results. So A64 should have 215/223 seconds (according to here:http://www.anandtech.com/linux/showdoc.aspx?i=2127... instead of 289 seconds.
I don't know if there are any others, but I would suggest you check all your benchmarks again carefully.
johnsonx - Monday, August 9, 2004 - link
My oh my, they do come out of the woodwork when AMD loses a set of benchmarks.Do you all measure your self-worth by how AMD does in benchmarks?
Really, do you all honestly think that 200Mhz more and more L2 cache would really change anything here? That's all an FX-53 or Opteron x50 would gain you, 200Mhz and 512K cache.
AMD Fanbois have such chips on their shoulders... is it really that big a deal that an Intel XEON beat your beloved Athlon64 at what was supposed to be it's own game?
Gee, maybe if you all bitch and moan enough Kristopher will 'fix' the graphs so you'll stop crying. Maybe you can get him to delete the ones where the XEON was faster (oh, that's almost all of them...).
Well, goodnight AMD worshippers. I'll laugh at your flames in the morning.
Dave
(p.s. after these benchmark results, I guess I better not deliver these two dual-opteron servers I have here all boxed up and ready to go. Now that I've found out Opterons suck, it just wouldn't be honest to deliver them... nope, I'll have to send back the mainboards and CPU's and order the obviously superior Intel XEON platform)
KristopherKubicki - Monday, August 9, 2004 - link
The only reason we even put the 3500+ in there is cause we already had benchmarks for it.Relax, its just a primer for future articles. A 3.6F is supposed to compare with a "3600+" rated Athlon 64 isnt it? Since we dont have a 3600+ the 3500+ should perform slightly lower? Isnt this what we expected? And for those of you who dont believe me, a 3.6GHz 1MB EM64T Nocona is *exactly* like a 3.6F.
I thougth the AMD chip did pretty damn good for costing $500 less!
Kristopher
ThePlagiarmaster - Monday, August 9, 2004 - link
I have a problem with which cpu's were compared. You should have included a NON 64bit P4 3.6 as others said to see if 64bit did anything). I'd also have liked an FX in there since you're comparing an $850 chip to 3500+ (perhaps more cache really helps here, and FX has double). These are benchmarks we know NOTHING about (do they favor large caches? etc). You also should state VERY CLEARLY which benchmarks ARE 64bit on 64bit OS. We know that A64 is faster in everything Windows. I've never heard of any of these except PovRay. We see here in an old anand article that 64bit shows around 15-20% (34% on Lame) improvement on A64: http://www.anandtech.com/showdoc.aspx?i=1884&p... I'm having a real problem believing Intel could make up 34% in lame with MS (and a few linux companies) saying Intel's 64bit isn't as good as AMD's. Some people calling it a software emulation hack basically.Here's another, look at those encryption 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...
Times cut in half on some, look at zipping too. In less than 1/2 here! Thats 2x+ faster. I really have to suspect these benchmarks with numbers like these out there. Are these 64bit or not that you used? This review does us no good if we can't tell if they are even firing up 64bit. Are they just some old benchmarks written for Intel basically or made for new systems? If you're trying to show a difference you must (at the very least) compare only benchmarks that show 32bit vs 64bit.
"These are both 64-bit CPUs, and so, all benchmarks are run on 64-bit OSes with 64-bit binaries wherever possible." So where was that exactly? You used synthetics everywhere, which in the past have shown intel in a good light when the real world apps/games show something COMPLETELY different. At least Xbit did 32bit+32bitOS vs 32bit+64bitOS AND 64bit+64bitOS. Thats something we can get some data from. That was written Sept 2003! You can't find better benches today? Synthetics have NEVER been shown to reflect the realworld. Quite the opposite in fact.
Another Encryption AMD vs. Intel (itanium 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?... Granted they are on windows (I think?), but we've been told by MS and other companies that Intel's 64bit sucks compared to AMD's. What gives here? Intel's chip has gained 800mhz, and AMD's has gained 600mhz (since your opteron article). AMD's 600 is worth more per clock than Intels 800. So how did they trounce AMD? The FX score would have shed a little more light here, but if things didn't even up, something's a bit fishy with these benchmarks. We need some answers here methinks. Not 'Intel's 64bit trounces AMD in benchmarks you've never heard of, oh and we're not even going to tell which are 64bit, and no 32bit vs. 64bit to even show if its a 64bit win or just more fake synthetic crap scores'. Yes, I know what a run-on sentence is...heh. I could go on, but I think I've provided ample "other" benchmarks that show complete reverse or serious AMD 64bit improvements. Besides it's 2am, I'm wiped out.