Compiling Benchmarks

We get a lot of requests to show some compiling benchmarks. Those playing Gentoo at home should be paying particular attention to this portion of the benchmark. We took the standard Linux 2.6.4 release from kernel.org and compiled it under our 32-bit test bed. We did not cross-platform compile for simplicity, so we are only looking at the 32-bit vanilla kernel. We used the commands as below.
# yes "" | make config
# time make

32-bit Linux 2.6.4 Kernel Compile

We are greeted with a nice slow performance curve. We have the slower 3.4GHz P4EE overtake its faster 90nm counterpart on several occasions now - a definite trend has set in. Below, you can see how the Intel processors favored when we enabled HyperThreading.

HyperThreading: 32-bit Linux 2.6.4 Kernel Compile

Keep in mind make is not actually threading, we are just determining what kind of a performance hit occurs by enabling the two virtual processors rather than keeping just one active. Obviously running two applications at once will receive performance benefits. The unfortunate fact remains that workstation software continues to remain largely linear. We receive some benfiit by running multiple applications at the same time, like rendering a file and playing an MP3, but there are very few Linux workstation programs that fully utilize multiple threads. Fortunately, we have an article coming up that deals with just how to receive the best performance out of multiple threads (and HyperThreading/SMP configurations) in the works.

We two additional tests with the Prescott processors calculating the time to make the kernel while forcing make to run parallel jobs.

HyperThreading: 32-bit Linux 2.6.4 Kernel Compile


HyperThreading: 32-bit Linux 2.6.4 Kernel Compile


It is very easy to use make -j* incorrectly. There are small perecentage gains by using make -j3 over make -j2 using HyperThreading.
Chess Benchmarks Synthetic Benchmarks
POST A COMMENT

33 Comments

View All Comments

  • - Saturday, October 24, 2009 - link

    sell:nike shoes$32,ed hardy(items),jean$30,handbag$35,polo shirt$13,shox$34 Reply
  • Hugh R - Thursday, September 23, 2004 - link

    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.
    Reply
  • bobbozzo - Tuesday, September 21, 2004 - link

    You should be running all the compilation test with -j2 or higher, as otherwise the CPU is waiting for the disk more often.
    Reply
  • uyu - Tuesday, September 21, 2004 - link

    Consider re-evaluating the test with the icc compiler:

    http://www.intel.com/software/products/compilers/c...

    I do not think it will only favor the result of intel processors..
    Reply
  • Zebo - Tuesday, September 21, 2004 - link

    Why separate the graphs? Afriad of people easily visualizing major A64 ownage? Gawd that's hard to compare that way... I had to get out pen and paper. Reply
  • Shalmanese - Tuesday, September 21, 2004 - link

    "throw an alternative opterating system"

    I like the attempt at subliminal advertising :D.
    Reply
  • TrogdorJW - Monday, September 20, 2004 - link

    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. Reply
  • injinj - Monday, September 20, 2004 - link

    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:

    cmpl $1, 8(%esp)
    sbbl %eax, %eax
    movl 8(%esp,%eax,4), %edx
    bsr %edx, %ecx
    jz l4
    andl $32, %eax
    subl $31, %ecx
    subl %ecx, %eax
    ret
    l4: movl $64, %eax

    The cmpl splits a 64 bit word into a 32 bit hi and lo words, so crafty will naturally exploit 64 bit instructions.

    This same function on x86_64 can be done much fewer instructions:

    asm (
    " bsrq %0, %1" "\n\t"
    " jnz 1f" "\n\t"
    " movq $-1, %1" "\n\t"
    "1: movq $63, %0" "\n\t"
    " subq %1, %0" "\n\t"
    : "=r&" (dummy), "=r&" (dummy2)
    : "0" ((long) (word))
    : "cc");

    These are critical functions in crafty and if you see benchmarks comparing 64 bit crafty to 32 bit crafty, this is primarily why 64 bits is faster.
    Reply
  • mczak - Monday, September 20, 2004 - link

    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.)
    Reply
  • PrinceGaz - Monday, September 20, 2004 - link

    The mouseover images work fine for me (Firefox 0.9.3) Reply

Log in

Don't have an account? Sign up now