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
WiZzACkR - Tuesday, August 10, 2004 - link
Regarding Post: 166 - Posted on Aug 10, 2004 at 9:28 AM by ss284hi steve - just a short reply. first of all let me say sorry for definitely overreacting, BUT:
"just mentioning that you seriously post in the [H]ardforums drops your credibility to 0. Saying that Hardocp, and especially the disgustingly bad hardocp forums come even close to Anandtech and its forums are an insult."
i don't really know where you have such a bad impression from, and frankly i don't care. however, for someone calling me biased and accusing me of "huge sweeping assumptions" this seems put you into the same boat, doesn't it?
"obviously written by that of a person who has done minimal research and has made huge sweeping assumptions."
it's actually quite simple: i just had their forums open at the time i was writing! look at the huge posts here in anandtech's forums ( http://forums.anandtech.com/messageview.cfm?catid=... ) or in whatever forum you want (just as another one you may want to look here http://www.aceshardware.com/forum?read=115093788 ) - it' everywhere ppl ranting over the review. so don't call me biased, don't accuse me of simple sweeping assumptions or minimal research. mind you - the wording here in anandtechs forums about the topic was not one bit better than the [H] forums...
"Oh, and FIFI, insulting people loudly with the intent to attention only shows how much your typical, non insulting postings command no respect or deserve any thought whatsoever, and that the only way for you to get a reponse is to yell."
i admit this is true and again want to apologize for overreacting. however, this remains the poorest review i've read at anandtech's for YEARS and think articles like this HAVE to go through an editors office - and prevented from being published!
"Last I checked it was AMD that came up with these processor ratings. Yet they dont seem to be taking any of the blame. A PR rating of 3500+ means its supposed to be competing with intel's p4 3.5, which doesnt exist. Kris took the nearest speed, a 3.6, and mentioned that in the review."
ok, you got a point there i admit. however, intel themselves is changing to a non-performance related numbering scheme and the article is comparing a $850 SERVER chip against the cheapest 939 MID-Level DESKTOP cpu. AMDs PR-rating scheme was designed comparing them to the previous generation of intel CPUs. put it ups against something equally expensive and a SERVER chip i say, but giving the unavailable 3.6F as an excuse i find inappropriate.
"Its sad to see how many horribly biased morons are posting this crap."
you have to admit it's the whole freaking internet you are talking about, as i really do not represent a minority here...
"Yes, there were problems with the article, and Kris is actively trying to remedy it."
then change the last paragraphs and not just add this little update-thing at the very end. how can you correct the benchmarks and then leave the conclusion the same - even though the first benches now show the 3500 winning (still being 500 bucks cheaper)?
"He is even testing an opteron system per request. Yet people continue to flame. Maybe you should offer some constructive criticism instead of going off on lame conspiracy theories and dooming the fate of Anandtech."
Let me say again i am sorry for the wording i chose - and again that a site as reputable as anandtec's is HAS to edit articles to prevent this from happening. sorry, there is just no excuse for dropping the ball so badly. i wouldn't even have cared if it wasn't one of the most professional sites on the net.
"If this is seriously how you feel, dont bother posting anymore. If the content is that bad, dont bother reading it."
i was so upset mainly because lots of ppl are reading this and take it as a fact, go out and buy a product. it's not about me really.
to put this to an end: excuse my swearing, it'll not let it happen again, but all criticism about the article still seems valid to me.
kresek - Tuesday, August 10, 2004 - link
Wouldn't a "openssl speed" make a better encryption test?John the Ripper uses some quite outdated assembly routines, and imvho does not represent a typical encryption workload.
Matthew Daws - Tuesday, August 10, 2004 - link
Okay, an update after reading over at Ace's. GCC under 64-bit linux does default to 64-bit mode (as expected). No idea what processor it defaults to though. There is also some suggestions that -O3 would make a big difference. There are some quite powerful critiques of Jack-The-Ripper as well:"The key parts of the tests John the Ripper runs are written in ancient assembler code, with different routines for an intel CPUID. From what I can see, the AMD code path uses 8 bit operations half the time and does a lot of memory copying! COmpletely invalid to use this as a benchmark."
--Matt
kresek - Tuesday, August 10, 2004 - link
johnsonx - Tuesday, August 10, 2004 - link
I've read and read and read all this drivel in here, and I still don't get it. Everyone keeps complaining what a bad CPU Review this is; back to my earlier point about borderline illiteracy, did anyone notice the title of the article?"Linux and EM64T: Intel's 64-bit suggestion".
Doesn't sound like a CPU review to me. Sounds like a quick preview or first look at running 64-bit linux on the first x86-64 capable Intel processor AT had gotten their hands on. That's how I read the article.
Also, why does everyone take the conclusion line out of context:
"Without a doubt, the 3.6GHz Xeon trounces over the Athlon 64 3500+ in math-intensive benchmarks."
Everyone who quotes this line leaves out the "...in math intensive benchmarks.". Why is this incorrect? What other conclusion could be drawn from the benchmark results? Sure I guess if you want to get really picky and legal about it, it might have said "....in THE math intensive benchmarks WE RAN". But seriously, what other benchmarks would he be referring to?
ianwhthse - Tuesday, August 10, 2004 - link
I don't know about the rest of you, but I do thank my mailman.Matthew Daws - Tuesday, August 10, 2004 - link
John the Ripper really needs some better work on the GCC flags. The generic configuration tries to optimise for a 486, which is why it fails (I would have, ahem, expected this to be obvious to someone doing a linux benchmark). The supplied text files indicate that "John optimizes itself during the build" is certainly not the case. The following flags are used:-c -Wall -O2 -fomit-frame-pointer -funroll-loops
Does anyone know what the default CPU target is? There is not explicit -mtune or -mcpu command, and no explicit command to use SSE(2) for math processing (hmm, a check shows that the x86-64 compiler defaults to SSE for math). For something like encryption, I would expect that optimisation would have a HUGE difference, so for the nocona (with GCC 3.4.1) I'd use -march=nocona. You can force 64-bit support with the -m64 command, which might be worth trying. Also, what about using the -O3 command or the -ffast-math command?
Anyone got a 64-bit linux system and know what target GCC defaults to? I can only presume 64-bit.
I've just downloaded the source-code from http://www.openwall.com/john/ and it appears that there are specially optimised modules to use x86 options (e.g. MMX). These are NOT being compiled in your test (from checking the attached transcripts). There is also a BETA version which offers much improved performance. You might consider using this?
Also, from my (limited) understanding of encryption algorithms, they don't use "math" (which tends to mean floating-point code as far as computers go) but use bit-twidling and such-like. This makes the fact that Nacona can thrash the Athlon 64 even more surprising (and hence suspect).
Just a few thoughts, --Matt
Arias74 - Tuesday, August 10, 2004 - link
Ok, I guess it's time to throw my $.02 into the mix. I've almost all the posts, and I think I understand the frustration.First of all, let me just say that I am a fan of AMD's processors. Within the past 6 months, I've puchased for myself or work several Opterons, an Athlon 64, and about a half dozen Athlon XP's. So, I'm fairly familiar with their products. That doesn't mean that I like Intel, only that I prefer AMD.
I think the most objectionable point in the article for me, and probably for most people, is the conclusions that the reviewer derived from his benchmarks. Especially the first sentence of the second paragraph "Without a doubt, the 3.6GHz Xeon trounces over the Athlon 64 3500+...", it seems to me that the conclusion was written to generate more of a "sound bite" than anything. In fact, I was pointed to this article from another website that used that line as a quote. And for you Intel fans out there, how would you feel if a website of technical merit published a review and declared "Intel's latest offerings is a joke compared to AMD's products...". Seems a little biased, don't you think? And the few corrections made throughout the article barely make it onto the conclusions, as an afterthought or a p.s. line at the bottom.
I've always relied on Anandtech to give very thorough and useful reviews of products. It's almost a given. However, with this current review, I am sincerely beginning to doubt that. With a review filled with numerous errors, I would think that a correction AT THE BEGINNING of the article would be the least that could be done, not at the end.
Also, I have to say that the choice of benchmarks should be seriously reconsidered. As many people have already pointed out, synthetic benchmarks are entirely useles compared to real world applications. I think one of the best reviews I've read in recent memory is the Anandtech Database performance shootout (http://www.anandtech.com/IT/showdoc.aspx?i=1982). You present 2 competing architectures and use them in a real world environment to derive a solid conclusion. These are the types of benchmarks to use when comparing enterprise level hardware. And if you decide to use desktop level hardware, use benchmarks that users can relate with, including gaming benchmarks and the like. It's difficult to make a definitive statement comparing two products when the methodology is flawed. Synthetic benchmarks are just that, synthetic. The only way to use them is to compare to similar products, such as a Prescott from a Northwood, or an Athlon 64 to an Athlon XP. In any other case, it's always best to use real application benchmarks.
Unfortunately, I have to say that the review was simply a waste of my time. Why? Because unlike other Anandtech.com reviews, I came away knowing that I learned nothing from the review. Nothing in the review made sense, from the choice of processors, to the choice of benchmarks. It was very disapointing.
Sorry for the long post... just wanted to say what was on my mind...
tfranzese - Tuesday, August 10, 2004 - link
#166, it's a poor comparison anyway you slice it. Anandtech assumes most of it's readers are not who the PR rating is targeted at persuading. This has been made clear in the past. You don't compare by number but by price and by performance.ss284 - Tuesday, August 10, 2004 - link
Regarding post: 159 - Posted on Aug 10, 2004 at 3:12 AM by WiZzACkRJust mentioning that you seriously post in the [H]ardforums drops your credibility to 0. Saying that Hardocp, and especially the disgustingly bad hardocp forums come even close to Anandtech and its forums are an insult. Then again, your post seems of the typical hardforums quality, biased, and obviously written by that of a person who has done minimal research and has made huge sweeping assumptions.
Oh, and FIFI, insulting people loudly with the intent to attention only shows how much your typical, non insulting postings command no respect or deserve any thought whatsoever, and that the only way for you to get a reponse is to yell.
Another thing, people are still complaining about the comparison. He has already mentioned that this is the same thing as a 3.6. Last I checked it was AMD that came up with these processor ratings. Yet they dont seem to be taking any of the blame. A PR rating of 3500+ means its supposed to be competing with intel's p4 3.5, which doesnt exist. Kris took the nearest speed, a 3.6, and mentioned that in the review. Not to mention the favorable timings on the AMD system.
Its sad to see how many horribly biased morons are posting this crap. Yes, there were problems with the article, and Kris is actively trying to remedy it. He is even testing an opteron system per request. Yet people continue to flame. Maybe you should offer some constructive criticism instead of going off on lame conspiracy theories and dooming the fate of Anandtech. If this is seriously how you feel, dont bother posting anymore. If the content is that bad, dont bother reading it.
In every review, kris had paid attention to the comments, and even actively participates in the forums. He takes suggestions, and usually makes good on them. Give him some time, and I'm sure the article will satisfy at least half of you. Some fanatics will go crazy no matter what, whether AMD or Intel.
-Steve