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
redpriest_ - Monday, August 9, 2004 - link
Better quality than a rush job IMO. I don't think the systems were even set up right. Remember the extremetech fiasco where the memory was running at *half* speed the entire time they had the FX51 and for a good portion of the FX53 time period?manno - Monday, August 9, 2004 - link
fifi"So keep on the sarcasm and hopefully it will improve your mental abilities which are clearly being impaired by the background EM waves, you SHOULD have bought those aluminium hats like I told you to..."
Yeah I can be a bit of a sarcastic pr#$%. Sorry about that :)
But look here's my thing AT posted a preliminary review, and that's obvios I mean they're using a A64 3500 and comparing it to Intels latest and greatest. And they posted numbers that showed that in some benches the new intel chip is better than AMD's 3500. It's a quick little heads-up review. And there are posters on here treating it like a full fledged benchmark suite. The numbers they got were the numbers they got. Do with them what you will. They told you what the benches were if you think there's somthing fishy going on do us all a favor and run the benches yourself and post your results for the rest of us, I for one wouldn't mind seeing another set of numbers quote:
"The delicate bit for this review was using the SuSE 9.1 Pro (x86_64) installation rather than compiling it from scratch (à la Gentoo). This was done to preserve the ability to replicate our benchmarks easily."
Look they stuck their head out and released some early numbers, and rather than thank them for doing it, people are throwing tomatoes at them. That's where I stand. Yes I would like to see more numbers on more chips, and that will come in time. For right now however this is what they have and it's what they released. So again I'de like to say thanks for giving me a heads up.
-manno
redpriest_ - Monday, August 9, 2004 - link
Something is seriously wrong with the 3500+ setup. Independent verification with the exact same compiler settings, only on a worse configuration (3200+ A64) show this:http://www.siliconinvestor.com/stocktalk/msg.gsp?m...
tpinckney - Monday, August 9, 2004 - link
I don't think anyone would be pissed off if it was a simple matter of the Xeon beating the A64 (probably disappointed would be a better word). The issue is the poorly done, inaccurate, and questionable benchmarks as well as a comparison between two chips that makes little sense.Manno and JohnsonX, please try and keep your posts above a third grade level.
redpriest_ - Monday, August 9, 2004 - link
There's a lot more wrong than just the MySQL numbers. Using TSCP, this guy gets phenomenally better results than what is portrayed. I would suspect the Xeon results would be much better as well if compiled under the same flags:http://www.aceshardware.com/forum?read=115093819
The fact of the matter is, these binaries do not seemed tuned for AMD64 at all.
jshaped - Monday, August 9, 2004 - link
yes, i too joined just so i could comment on this article.
i agree with johnsonx - most of Anand's readers must be illiterate, or half-way oblivious.
take this article for nothing more than it was meant - it was a quick and dirty benchmark of a non-existent processor - that's it.
quit whining about A64 vs. Xeon - as johnsonx said the Xeon is 99% the same as a p4 - it's always been that way. please read what the author of the article said - this is just a primer for future articles.
anand's received this non-existent processor from unnamed sources, and they did what any of us would've done - quick and dirty benchmarks with what they had readily available.
chill
johnsonx - Monday, August 9, 2004 - link
Dear KK,Please don't post any more articles that don't show AMD stomping over Intel in every benchmark (except of course video encoding, which AMD Fan has graciously allowed Intel to win).
This way we can avoid furhter diarrhea of the keyboard.
Regards,
Dave
johnsonx - Monday, August 9, 2004 - link
Yes, it would be nice to have an edit feature on these...I meant of course:
XEON 3.6 EM64T = Prescott core, 3.6Ghz, 800Mhz FSB, 1Mb L2, EM64T enabled.
Pentium 4 3.6F = Prescott core, 3.6Ghz, 800Mhz FSB, 1Mb L2, EM64T enabled.
johnsonx - Monday, August 9, 2004 - link
to #20, srg,oooh, ouch, you called me an Intel fanboy.
First, as I pointed out, the only difference between the tested AMD cpu and the very best FX-53 or Opteron x50 is 200Mhz and 512K more cache. 200Mhz isn't going to make the difference, nor is the extra cache. Anandtech has shown numerous times that K8 is not cache starved at all. At best, the top AMD CPU would be 10% faster.
Second, as KK pointed out, the difference between the tested XEON and the P4 3.6F is NOTHING, aside from the 603-pin socket and the E7525 chipset. A P4 3.6F on a 925X chipset would produce exactly the same numbers.
XEON 3.6 EM64T = Prescott core, 3.6Ghz, 800Mhz FSB, 1Mb L2, EM64T enabled.
XEON 3.6 EM64T = Prescott core, 3.6Ghz, 800Mhz FSB, 1Mb L2, EM64T enabled.
Many of the comments here make me think much of the Anandtech readership is bordeline illiterate. For example KK points out that "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." I guess the Dick and Jane readers had trouble sounding that one out, or they couldn't apply that nugget of info before flaming that the Opteron was faster than XEON before, so why isn't it faster now!?!?!? XEON has changed quite a bit since then Reader Rabbit.
About the only comment in this whole rant I agree with is the one just after my first: #19 fifi pointed out that there is likely a mistake in the MySQL Select numbers, as the last place showing of the A64 doesn't match KK's comments about A64 winning this test.
Stinger22 - Monday, August 9, 2004 - link
Horrible review... Please get an Opteron 150, provide more details on the testing done, and please throw some more variety in there (like additional cpus (32/64bit/different speeds etc..) and how they perform on these err.. tests lol), oh and do it right next time.Btw, I registered for the forum just to post this. Yes, it is that bad!