If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Debian Wheezy GNU/kFreeBSD: Slower Than Linux

06-25-2012, 01:00 AM

Phoronix: Debian Wheezy GNU/kFreeBSD: Slower Than Linux

With Debian 7.0 "Wheezy" set to be frozen soon, I took the opportunity to run some new benchmarks of Debian GNU/kFreeBSD, the Debian OS variant using the FreeBSD kernel rather than Linux, to compare it to Debian GNU/Linux as well as Ubuntu Linux and PC-BSD/FreeBSD 9.0.

Comment

Probably because BSD does not get as much attention and developers when it comes to the parts Michael tested, and thus those parts are not as optimized on the BSD-side as on the Linux-side.

Or the BSD kernel itself is inherently slower than Linux?

Wouldn't surprise me; there's been a ridiculous amount of investment in Linux lately. Sure, you can't just fix any problem by throwing money at it, but at least in computer science, you can develop new algorithms with really impressive average and worst-case performance. I know they're very careful about algorithm selection and use in the Linux kernel, and that's one of the main areas where Linux beats out pretty much everyone.

Since these tests mainly benchmark CPU based operations, this comes as no surprise that Linux would be faster. It has an amazing scheduler; BSD doesn't.

These benchmarks aren't testing I/O performance (disk) or GPU performance, so I'm not sure what to make of it. I'll bet that Linux is still faster for GPU performance, but it remains to be seen how they'd stack up on the disk I/O front. I'm not so confident that Linux would take the cake there, because ext4 at least is pretty slow in some of the tests we've run on it. It's a pretty lopsided filesystem: some tests, it performs amazingly well; others, it falls down completely. I'd actually want to see how XFS stands up against BSD's filesystem (ZFS, I guess). XFS is not going to blow you away with amazing numbers in any one test, but it's designed so that it pretty much can't get into a horrible worst-case performance scenario... so you aren't going to see it performing at only 10% the speed of ZFS on any of the benchmarks, either. It'll be right up there with it, and occasionally excelling.

Comment

I just setup my laptop with ZFSOnLinux as root fs and Gentoo last weekend. Works fine so far except of grub2 didn't like to boot the pool directly, so it needed an extra 100MB boot partition.
As soon as I decided on a GUI (DE) etc. I'll try to run some benchmarks...

Comment

Wouldn't surprise me; there's been a ridiculous amount of investment in Linux lately. Sure, you can't just fix any problem by throwing money at it, but at least in computer science, you can develop new algorithms with really impressive average and worst-case performance. I know they're very careful about algorithm selection and use in the Linux kernel, and that's one of the main areas where Linux beats out pretty much everyone.

Since these tests mainly benchmark CPU based operations, this comes as no surprise that Linux would be faster. It has an amazing scheduler; BSD doesn't.

These benchmarks aren't testing I/O performance (disk) or GPU performance, so I'm not sure what to make of it. I'll bet that Linux is still faster for GPU performance, but it remains to be seen how they'd stack up on the disk I/O front. I'm not so confident that Linux would take the cake there, because ext4 at least is pretty slow in some of the tests we've run on it. It's a pretty lopsided filesystem: some tests, it performs amazingly well; others, it falls down completely. I'd actually want to see how XFS stands up against BSD's filesystem (ZFS, I guess). XFS is not going to blow you away with amazing numbers in any one test, but it's designed so that it pretty much can't get into a horrible worst-case performance scenario... so you aren't going to see it performing at only 10% the speed of ZFS on any of the benchmarks, either. It'll be right up there with it, and occasionally excelling.

clearly the x264 and the ffmpeg tests assuming 100% CPU use at the time tells you all you need to know , Debian GNU/kFreeBSD has some serious bottlenecks that NEED looking at and sorting ASAP.

x264 and the ffmpeg tests, and even Chris Wilson's SNA hardware-specific optimisations and micro optimizations all show you the massive benefits and the need today to actually benchmark and re-write all your separate code routines and macro's etc to get far better throughput and also remove code cruft on a consistently regular basis, writing "good enough if it works" code is clearly not good enough today, you need to be better and make the time to write quality benchmarked code and actually test it for speed as well as correctness before you commit that latest patch.

<as if it's not abundantly clear: sarcasm>That was a joint conspiracy from Apple and Windows to encourage more BSD development so that they can steal the code and linux will suffer ;-)</sarcasm>

Apple and Microsoft do encourage more BSD development, so they can steal from it.
Because BSD license has no freedom protection clause, as in free to do whatever you want.

This results in any commercial OS based ON BSD code to be faster, better and more efficient than ANY BSD.

Which in turn has three multiple consequences for BSD:
- to exist only and only in shadow
- to receive just a corn from the table, donated
- to be breeding pool for non-free software, just like a dead cow corpse for worms, worms have shown hostility towards open-source software that PROTECTS its freedom.

Comment

I see a pattern emerging, it seems consistent for BSD to be a little slower than Linux

Oh yeah, it's 1.5-2 times slower in quite many tests and by 4 whole times slower in openssl. "A little slower". Hmmph.

Though I'm fail to understand how exactly *BSD guys managed to get such a bad results on same hardware. They managed to both get crapwrecked CPU scheduler and poor syscall servicing times? Broken hardware initialization? Or how they could lose whole 4 times in openssl which is more or less computational test? It does not even requires servicing many syscalls!