Linux and EM64T; Intel's 64-bit Suggestionby Kristopher Kubicki on August 9, 2004 12:05 AM EST
- Posted in
Audio EncodingLame 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-RAYAlthough 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.
GZipTo 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 PerformanceWe 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.
Post Your CommentPlease log in or sign up to comment.
View All Comments
Jeff7181 - Monday, August 9, 2004 - linkOoops... I really wish it was possible to edit these. =) What I meant to say was...
"... especially since 2/3 of those benchmarks..."
Jeff7181 - Monday, August 9, 2004 - linkI would like to see some Pentium 4 3.6 GHz numbers in there too so we can see the effect of Intel's x86-64 support. With the data available, it's impossible to decide whether Intel has integrated it properly and gets a performance boost, or if a 3.6 GHz Xeon is just naturally that much faster than an Athlon-64 3500+... especially since 92/3 of those benchmarks are not benchmarks I've ever seen you run before so I have no idea how ANY other processor compares.
Sorry Kristopher, but this was a BAD article. There's not nearly enough information to draw any useful conclusions.
gimp0 - Monday, August 9, 2004 - linkthis was probably the worst comparison ever. At least give us some game benchmarks like UT2004 64bit and let us see some real numbers.
Server CPU against a mianstream chip in a database environment will surely favor the xeon.
the5thgeek - Monday, August 9, 2004 - linkwhat is the reason for comparing the new intel processor against the slowest socket 939 processor? why not a FX53 or 3800?
DrMrLordX - Monday, August 9, 2004 - linkWhat the hell made you run a 3.6 ghz Nocona vs the 3500+?!? Try running it against an Opteron 150! For crying out loud . . .