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.

lame 1.96


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 3.05c

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.


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

Gzip 1.3.5

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.

MySQL 4.0.20d - Test-Select

MySQL 4.0.20d - Test-Insert

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.
Index Synthetic Benchmarks
Comments Locked


View All Comments

  • tfranzese - Tuesday, August 10, 2004 - link

    Which tests were re-ran? I guess I should ask that first.
  • KristopherKubicki - Tuesday, August 10, 2004 - link

    #203 can you be more specific? What is wrong with my conclusion.

  • tfranzese - Tuesday, August 10, 2004 - link

    What more do we want? Fix the rest of the article, including the conclusions you drew.
  • KristopherKubicki - Tuesday, August 10, 2004 - link


    Jasons article is seperate from mine. His is running on windows anyway with two processors.

    "f-off people" is strictly not my attitude. I have made changes to the article that were suggested; i fixed the broken makefile, i even did another article on my vacation with an opteron 150 to be posted within the next 24 hours.

    What more do you want? Really?

  • MikeEFix - Tuesday, August 10, 2004 - link

    There is nothing wrong with an engineers’ pov. We tend to like symmetry and base results on facts. Unfortunately there is little symmetry and too many variables for accurate results.
    Experiments should be kept in the lab
  • allnighter - Tuesday, August 10, 2004 - link

    A few days ago when Nocona was announced I shouted I wanted some benchmarks.When Jason Clark mentioned AT is working on some benchmarks I was very excited. Now I am am not. This article is... well in attempt to be polite... of a very questionable quality or simply crap.
    As many people posted their observations, whith most of which I agree, this is not quality we're used to from AT. And all the AMD and Intel fanboyish escapades in here are just making all this worse.
    I feel like something should be done. I have no idea what but just one 'f-off people' type of comment from the author is just not doing it for me. This is bad.
  • Pumpkinierre - Tuesday, August 10, 2004 - link

    Good on ya Kristopher, you got a bit of scientist in you unlike some of these machine like engineer types. Some of us know where you are coming from (and it aint Intel). A little knowledge can be a dangerous thing but its still better than no knowledge at all. Looking forward to your later articles on the subject.
  • MikeEFix - Tuesday, August 10, 2004 - link

    Well the nvidia 250 reference board isn't exactly a Tyan Thunder K8W(S) either.
    The Xeon is using platform $600.00 server mainboard while the desktop variant, a64, is using the generic desktop solution.
  • Macro2 - Tuesday, August 10, 2004 - link

    This is the kind of article i'd expect from Tom's not Anandtech. I guess Anand is out with the lady.
  • srg - Tuesday, August 10, 2004 - link

    Well with these refinements an updates to the benchmarks, not forgetting setting them up right, the gap is closing to what I would have though it would have been, although the Jon-The-Ripper benchmark does seem odd (explained better my an earlier poste, if he's right then the 3500+ is basically running 64-bit'ised K6 code).

    I think what Kris has learnt here will be valuable for later reviews (and no, the simple fact that Intel beat AMD won't bring a torrent of flames like this one).


Log in

Don't have an account? Sign up now