Slashdot Mirror


Benchmarks of Debian GNU/kFreeBSD vs. GNU/Linux

An anonymous reader writes "The Debian Squeeze release is going to be accompanied by a first-rate kFreeBSD port and now early benchmarks of this port have started coming out using daily install images. The Debian GNU/kFreeBSD project is marrying the FreeBSD kernel with a GNU userland and glibc while making most of the Debian repository packages available for kfreebsd-i386 and kfreebsd-amd64. The first Debian GNU/kFreeBSD benchmarks compare the performance of it to Debian GNU/Linux with the 2.6.30 kernel while the rest of the packages are the same. Results are shown for both i386 and x86_64 flavors. Debian GNU/kFreeBSD may be running well, but it has a lot of catching up to do in terms of speed against Linux."

3 of 143 comments (clear)

  1. Phoronix by OverlordQ · · Score: 3, Interesting

    While they're really the only group that does a lot of linux benchmarking, I'd put a *large* grain of salt in their results.

    They have no problem blindly accepting something like this without investigating why it is so much faster and seeing if there's a problem with their testing.

    --
    Your hair look like poop, Bob! - Wanker.
  2. Please educate me a bit. by santax · · Score: 3, Interesting

    As a long time debian user who also has to work with freebsd sometimes I don't get it. Why use freebsd with GNU apps, when you can just run freebsd? And why freebsd and not lets say, openbsd or netbsd? What is the advantage in using the freebsd-kernel instead of the linux-kernel? I have access to every linux app when I use freebsd and to be honest, if I knew my way around bsd as I do under debian I would probably switch. But I am missing the improvement for Debian here. Can someone please clear this up for me a bit?

  3. Re:Holy moley ! by Sillygates · · Score: 3, Interesting

    But on x86, you are only guaranteed 4 *real* general purpose registers. x86_64 increases this number. With a good compiler, the register allocator would use all of these, and you would have much fewer loads from main memory, which can take on the order of 75+ cpu cycles on a cache miss, or 5+ cycles on a cache hit.

    --
    I fear the Y2038 bug