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
Anemone - Monday, August 9, 2004 - link
I just can't help but wonder, if you already knew, by numerous tests, that the math ability of the A64 is leaps and bounds ahead of the P4 or Xeon, didn't you want to question your results?I know the P4EE and the A64's are often neck and neck in some tests (obviously not Doom3 haha) so I'm not going to be shocked if Xeons do well in some apps. But there are literally thousands of posts of pi tests (of the many flavors) in which the P4 is soundly trounced in every single one of them, and by a large margin. The Xeon even the EM64T version is just a Prescott core, and quite honestly its math ability should not be, even in 64bit mode, night and day different from its current results.
Anyway, have to at least say you stood by your convictions and stated things as they were presented to you. And hopefully more information will help us all to understand if maybe the Xeon at least does relatively well in 64 bit, which would be a nice bit of news I think.
$02
SDA - Monday, August 9, 2004 - link
Funny, it looks like you're testing the 3500+ in 32-bit mode, in MySQL Test-Select at least...http://images.anandtech.com/graphs/amd%20and%20lin...
http://images.anandtech.com/graphs/linux%20and%20e...
Decoder - Monday, August 9, 2004 - link
Hello Kristopher,Some people don't know how to articulate their thoughts properly, as we see in this thread.
Anyways, for your followup review please test the 64 bit implementations by AMD and Intel using more than 4 GB of rams. 6 or 8 GB will do nicely. I heard Intel implementation relies on software where as AMD's is 100% hardware and this is where AMD Opteron's shine and Intel's EM64T has performance issues.
Again, testing 64 bit mode with 1 gig's is probably not worth it.
Regards,
Decoder.
tfranzese - Monday, August 9, 2004 - link
Some of you, the very few of you, that cannot see the problem with the quality, consistency, and lack of comparisons in this article compared to not only other sites, but this one's as well seriously need your heads checked. It's that simple.tfranzese - Monday, August 9, 2004 - link
I don't visit Anandtech (or any site for that matter) if I weren't expecting well thought out and quality articles. I don't think many here visit to see rushed out numbers and editorials. I don't thank a publication that thrives on users reading their material for sub-par work. Publications survive thanks to the readers and not the other way around.mino - Monday, August 9, 2004 - link
manno: U're Idiot or Intel PR (You can choose your favourite).Kris: The best thing to do is to either: COMPLETELY rewrite or call in this BS U produced.
No Offence. I'm disgusted.
danidentity - Monday, August 9, 2004 - link
You all sound like a bunch of whiny little babies. It's amazing how many people come out of the woodwork when something puts AMD in a bad light. I'm actually laughing outloud reading these commments.As KK pointed out, the upcoming P4 3.6F will produce extremely similar numbers to the Xeon benched in this article.
The P4 3.6 is a comparable processor to the 3500+.
fritz64 - Monday, August 9, 2004 - link
Hello Kristopher,I have been a silent member on this forum since I registered but this article made me search for my password in order to make a comment. You guys at Anandtech have been doing a good job of keeping us informed about capabilities of current day computer hardware. However this current review need serious attention and should be immediately considered based on the various opinion expressed in the forum.
I love to see more of number crunching on real applications using 32/64 bit set up. I mean 32-bit OS/32-bit compiler and 32-bit/64-bit AMD vs Intel.
As for the current review. I think the idea of using the installed Suse Linux OS 9.1 is not a real test of a hardware capability. The OS should be compiled for the best performance optimization on both Intel and AMD platform. Further, the use of 32-bit compiler for AMD Athlon 3500+ does not make use of its 16 registers and thus cripple it's performance a little bit. For best performance, Since Intel writes optimize compiler for their CPUs, I will suggest that you get the best compiler for the Intel system and bench it against the best compiler for AThlon 64 which is undoubtedly the PATHSCALE COMPILER SUITE ( YOU CAN GET A 30-DAY FREE DOWNLOAD VERSION AT www.pathscale.com). Whether the 30-day trial version consist of all the necessary optimization is what I don't know. However the PATHSCALE compiler gives the best SpecInt score that blows the Itanium2 away.
TauCeti - Monday, August 9, 2004 - link
to #74"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."
I wish i could agree with you, but:
Well, if the numbers are that early that you do not detect obviously wrong results, you should at least inform your readers that you have no idea at all what your benchmark results mean.
I mean: The TSCP Bench on the 3500+ produced a score BELOW 1.0. IF you use that arcane bench you should at least wonder why your 3500+ performs worse then a 2000+.
I cannot understand how one could publish a TSCP score below 1.0 without any comment on that.
FYI: TSCP defines score 1.0 (about 243k nodes/sec):
/* Score: 1.000 = my Athlon XP 2000+ */
Tau
fritz64 - Monday, August 9, 2004 - link
Hello,Testing. Please ignore