Although we have performed a few interesting benchmarks of processors on Linux in our past benchmarks, whenever I get cornered by a professor on campus or guest speak at a Linux Users Group, the first question anyone asks me is, "Which processor should I get for my new workstation?" Although the possibilities are totally limitless, the Linux users whom I have met generally have the mentality of "build something out of complete new parts, so it lasts" or "build something out of stuff that I find for free." Generally, the latter doesn't present many options, so today, we will address the first scenario - which new components make the ultimate Linux workstation. We found a few high end AMD and Intel processors to pit against our comprehensive Linux benchmark suite. Of course, don't forget to check out some of our other benchmarks including AMD Sempron, Opteron 150 and Nocona 3.6 from last month.
With so many socket, memory and processor configurations, recent computer configurations can be extremely confusing. DDR2 or DDR1? AMD or Intel? 1MB L2 cache or 512KB? HyperThreading on or off? None of these are easy questions, particularly if we throw an alternative opterating system in the mix. We set up all of our benchmarks so that they can be replicated easily by anyone using a similar configuration. Below, you can see which configurations were used for the benchmark analysis.
For the majority of the benchmark analysis, we leave the HyperThreading capabilities of the Intel processors off. Unfortunately, most workstation applications are not capable of multi-threading applications, and running HyperThreading penalizes the Intel processors when it isn't needed. We do run some benchmarks where multiple threads are utilized, and in those instances, we take some special consideration with multiple benchmarks. For most of our tests, you will see 32-bit binaries on 32-bit Linux kernels. Moving the mouse over these benchmark graphs will actually reveal the 64-bit tests that we have done with our Athlon 64 processors. The Intel processors in this analysis do not have 64-bit capabilities.
We also have a small DDR2 versus DDR1 comparison near the end of this article. For the Intel processors, we use the DDR2 memory provided by Corsair exclusively except for the DDR2 versus DDR1 comparison. We chose the MSI K8T board for our AMD tests, since it was one of the most stable and reasonabily priced motherboards for the 939 architecture. DFI won our spot as the Socket 775 test bed for its DDR2/DDR1 support and solid stability. Testing DDR2 versus DDR1 was extremely relevant to this motherboard, since we could just swap memory modules without changing motherboards. Let's jump right into benchmarking.
Generally, all of our benchmarks are taken three times and then the highest marks are recorded unless stated otherwise. Note that we have updated to the more current GCC 3.4.1.
Thanks for this article. It has been needed for about a year. Every previous benchmark of AMD 64 seemed to be 32-bit mode which is rather missing the point.
Firefox 1.0PR on LINUX did not show the 64-bit results until I went to edit:preferences:web features:enable java advanced... and turned on lots of crap (I don't know which item made the difference).
The information was fascinating but the presentation was very awkward.
When you see a surprising benchmark result, it is a good idea to analyze why you were surprised. For example, I would guess that the poor showing for 64-bit code on John the Ripper might be due to hand-coded x86 assembly code. Note: just a guess.
The fact that Wine is only 32-bit seems pretty uninteresting/unsurprising: Win32 binaries are also only 32-bit.
Few things in the LINUX world are binary-only, so almost anything for which CPU performance matters can and should be run in 64-bit mode on a 64-bit processor.
On the LAME encoding benchmark, isn't the actual value really "Play time divided by encoding time"? Or perhaps "Relative encoding rate"? Anyway, the text explains the graph better (in 1 second the 64-bit FX-53 encoded 25 seconds of audio). Otherwise, good stuff.
Crafty does have a bit of hand tuned asm for both x86 and x86_64. Most of the operations are done with boards packed into bit representations. For example, like this:
while (moves) {
to=FirstOne(moves);
*move++=temp|(to<<6)|(PcOnSq(to)<<15);
Clear(to,moves);
}
The FirstOne() function utilizes the bitscan ops of x86 (bsr = bit scan reverse), but notice the cmpl at the top:
what's up with the encryption benchmarks? "OpenSSL's crypt libraries are probably heavily optimized for 32-bit operation; we see the difference in the two architectures very clearly."
But the results show that 64bit mode is more than two times as fast as 32bit mode in one case (RSA), and 50% faster in the other case (AES)?
(and btw I haven't looked at johntheripper, but it might contain hand-optimized assembly for x86, but only generic c code for other architectures such as x86_64.)