Forgot your password?
Debian BSD Linux

Benchmarks of Debian GNU/kFreeBSD vs. GNU/Linux 143

Posted by timothy
from the slashing-for-both-teams dept.
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."
This discussion has been archived. No new comments can be posted.

Benchmarks of Debian GNU/kFreeBSD vs. GNU/Linux

Comments Filter:
  • by TheRaven64 (641858) on Wednesday January 20, 2010 @03:38PM (#30836286) Journal
    Okay, so I only read the first couple of pages because it's Phoronix who have a history of inflamatory and misleading benchmarks, but from what I saw:
    • Sometimes Linux is faster.
    • Sometimes FreeBSD is faster.
    • Usually the difference between the two is smaller than the difference between IA32 and x86-64.
    • The tests were mostly either CPU- or I/O-bound, so there are lots of factors beyond the kernel that would affect the results.
    • Debian kFreeBSD uses an old FreeBSD kernel, not sure how old the Linux kernel is but it's probably not representative of the speed of recent releases of either kernel.
  • Re:sigh (Score:3, Insightful)

    by MBGMorden (803437) on Wednesday January 20, 2010 @03:39PM (#30836298)

    Yep, because we ALL KNOW speed is EVERYTHING when running a computer.

    Of course it's not everything - but it IS a major part. Cost is another. We're at a tie there.

    So what's left? User friendliness? These systems use the same apps - tie there too.

    We're basically left with security and stability. If you want to write and article on those feel free - I'm sure Linux won't fare too bad there, but I'd like to see the results.

    Still though, to dismiss speed as a criteria is just being naive.

  • Re:sigh (Score:3, Insightful)

    by clarkn0va (807617) <{moc.liamg} {ta} {teg.tpa}> on Wednesday January 20, 2010 @03:41PM (#30836318) Homepage
    I think speed is everything when you're writing an article for a benchmark site. Note that I'm not disagreeing with your ironic implication that there are other things to look at, but obviously it's a lot easier to churn out some graphs than to try to compare two OSes/suites/whatever on other important metrics, such as security or usability. Leave that to the media troll sites--there's no shortage of them.
  • Re:Holy moley ! (Score:3, Insightful)

    by nedlohs (1335013) on Wednesday January 20, 2010 @04:00PM (#30836580)

    Where many is ~20% of them.

    And why would that be surprising? 64 bit lets you address more memory and they did the tests in a machine with memory that 32 bits could address all of. 64 bit pointers are obviously larger too, so the 32 bit version has effectively more memory and better cache usage.

    Some programs aren't going to take advantage of 64 bit registers and so on, but are going to suffer from worse cache performance.

    Stick 8 or 12 GB of RAM in and things might be different

  • Re:Holy moley ! (Score:4, Insightful)

    by DAldredge (2353) <SlashdotEmail@GMail.Com> on Wednesday January 20, 2010 @04:04PM (#30836632) Journal
    64-bit data structures can take up more space in the L1/L2/L3 caches which may cause code to run somewhat slower.
  • by maxwell demon (590494) on Wednesday January 20, 2010 @04:12PM (#30836754) Journal

    What about a performance comparison with original FreeBSD?

  • Re:Holy moley ! (Score:5, Insightful)

    by TheRaven64 (641858) on Wednesday January 20, 2010 @04:29PM (#30837030) Journal

    On most architectures, 64-bit code is slower. Pointers are bigger, which means you need more memory bandwidth to load them and you use more cache holding them. On x86-64, the situation is confused by the fact that 64-bit means 'using Long mode,' as well as 'using 64-bit pointers'.

    Long mode gives you 64-bit registers (so you can store 64-bit values in a single register, rather than spread across two, doubling the number of 64-bit values you can store in registers), more registers, and a few other benefits like removing the 'must use EAX as the target' restriction on a lot of instructions (reducing the number of register-register moves, and decreasing instruction cache usage as a side effect). 64-bit pointers use more memory bandwidth and data cache.

    For best performance on x86-64, you want pointers to remain 32 bits, but still run in Long mode. The OS should make sure that everything is mapped below the 4GB line for the process. As far as I am aware, no operating systems actually support this mode of operation. Without that, for any process using less than 4GB of address space, you have some advantages and some disadvantages when running in 64-bit mode. Whether the advantages outweigh the disadvantages, or vice versa, depends on the code.

  • Re:sigh (Score:4, Insightful)

    by TheRaven64 (641858) on Wednesday January 20, 2010 @04:41PM (#30837190) Journal
    The speed difference is a few percent. For most people, that's not noticeable. My kernel CPU usage stays well below 10% most of the time, even when the CPU is busy, so even a 50% difference in kernel performance wouldn't be particularly important. Much less important, for example, than things like ZFS, DTrace, a decent kernel sound system, and so on.
  • by bark (582535) on Wednesday January 20, 2010 @05:05PM (#30837530)
    It's NOT testing freebsd. the article tests the Debian world running with FreeBSD
  • by ls671 (1122017) * on Wednesday January 20, 2010 @05:22PM (#30837766) Homepage

    > Because every 64-Bit CPU I've ever used always had more than twice as much L2 cache as 32-bit Systems.

    I am glad I am using 64 bits CPUs to run my 32 bits OSes then ;-)

    Well unless somehow, the "twice as much" doesn't get used with 32 bits OSes running...

    What do you think ?

  • by r00t (33219) on Wednesday January 20, 2010 @05:29PM (#30837910) Journal

    In theory, perhaps.

    On that web page I see this: "The ports and doc trees use tags whose names begin with RELEASE tags." Excuse me, WTF? You're only going to tell me how the name begins and leave me to guess the end?

    Can I go back 15 years? Can I do this for versions 1, 2, or 3?

    What about all the stuff it drags in? Is the old source code actually there, or just the build system?

    I sure hope that a CVS checkout isn't going to drag a bunch of old history with it. Gigabytes would be unfriendly.

    I can go to Red Hat or Debian's site and just download the packages I want, either binary or source. Why does FreeBSD makes things so unusable?

  • Question? (Score:1, Insightful)

    by Murdoch5 (1563847) on Wednesday January 20, 2010 @06:33PM (#30839000)
    Why even swap the kernel out? The Linux kernel supports more hardware and has better stock performance then the FreeBSD kernel. In fact most friends I have that use FreeBSD are snotty to Linux users anyway. I say give them there OS and it's sorry performance (at least I've never seen anything comparable) and I'll stick with my stage 1 Gentoo which is fast, optimized and ready to go.

    Sorry if this offends any FreeBSD user as that's not my point but I've installed it a ton of times to try it out and I'm still waiting for an install that lets me say "Woah" from the get go. Sure you can optimize after the fact but that's not the point, fast out of the box, faster after the tweak! that's what I want and FreeBSD has never given that to me .

    If your a FreeBSD user great and if you a Linux user great, but lets not mix the two please!
  • by TheRaven64 (641858) on Wednesday January 20, 2010 @07:08PM (#30839464) Journal

    The benchmarks must be CPU or I/O bound... why should they benchmark sleeping apps?

    If they're I/O bound, userspace and kernelspace are both waiting for the drive. The layout of the files on disk will have more of an impact than the kernel. You are right that things should be CPU-bound, I should clarify that I meant userspace CPU bound. You want to benchmark things that are systemcall-heavy, like concurrent apps that use lots of synchronisation primitives.

    I really don't hope the last minute changes to the kernel, to do a big improve the system performance.

    FreeBSD development follows three branches. -CURRENT is where all of the latest stuff is. -STABLE is where stuff that has been tested a bit in -CURRENT goes. -RELEASE branches are where only bug fixes (no new features) go. The 8.x series began development as 8-CURRENT shortly after 7.0 was released (about two years ago). Some features were then back-ported to the 7-STABLE branch, but only those that could be moved without invasive changes that might affect system stability.

    8-RELEASE is the latest stable release and has had two years worth of new features on top of the one shipped with Debian, including, among other things:

    • Improvements to processor affinity and scalability in the scheduler.
    • A completely new USB stack.
    • A newer version of ZFS.
    • Improvements to the sound subsystem (now contains a full OSS 4 implementation, per-vchan volume control, a massively improved mixing algorithm, and other improvements)
    • A new NFS implementation, including NFSv4 support.
    • Network stack virtualisation for jails.

    It's not a matter of last minute changes, it's a matter of not getting the last two years of improvements. I know that Debian likes the stable-and-tested versions of things, but they don't seem to apply that policy to the Linux kernel.

  • by PhrstBrn (751463) on Wednesday January 20, 2010 @08:24PM (#30840410)

    I can see a really good usage case for this.

    You're a sysadmin, and you're running Debian almost exclusively. You have a large number of automation scripts that you use to do your job (security updates, auditing, provisioning, general maintenance, etc). All of them are expecting to run on Debian, because all you run is Debian. So you, as a sysadmin, decide you want to use ZFS somewhere.

    You have a few options:

    1) Run Solaris
    2) Run some derivative of BSD (FreeBSD, OpenBSD, NetBSD, etc)
    3) Run Debian w/ ZFS in Fuse
    4) Run Debian kFreeBSD

    Options 1 and 2 will most likely require you to tweak or rewrite a lot of your scripts. I shouldn't need to explain why option 3 is a bad idea. Since you're working with Debian userland, going with option 4 seems like it would be the path of least resistance. Seems pretty useful.

  • Re:Question? (Score:3, Insightful)

    by IMightB (533307) on Wednesday January 20, 2010 @08:37PM (#30840544) Journal

    I'm a Linux fan, but there's a first. A linux user complaining that he needs to tweak the OS to get the most out of it!

    Here's a tip, ALL OS's require tweaking to get the most out of them.

  • by r00t (33219) on Thursday January 21, 2010 @03:43AM (#30843286) Journal

    Yes, your slackware from 1994 is full of security holes. The FAIL here is you trying to install an unsupported version of the OS and then complaining about it when it doesn't work.

    Never did I suggest that I was running a random server exposed to the Internet. The box could be running some lab equipment that costs millions of dollars to replace, using a proprietary control program that won't run on a more modern OS. The box could be running a legacy app, with a modern system controlling things over a serial line. Shit happens.

    The fact that an unsupported OS suffers bit rot is disgusting. The bits should just sit there forever, as they do for every Linux distribution except Gentoo.

    I will never voluntarily put myself or my future successor in such a terrible position. Software needs to be available forever.

    No excuses!!!

"The value of marriage is not that adults produce children, but that children produce adults." -- Peter De Vries