Debian Testing: FreeBSD 10.0 vs. Linux 3.14 Kernels

[phoronix]

Phoronix: Debian Testing: FreeBSD 10.0 vs. Linux 3.14 Kernels

Debian GNU/kFreeBSD remains an interesting port of Debian that pairs its GNU user-land with the FreeBSD kernel. With the Debian testing code for Testing / Jessie 8.0 is the new FreeBSD 10.0 kernel. The benchmarks today at Phoronix are comparing Debian GNU/kFreeBSD to Debian GNU/Linux using the latest 7.5 Wheezy release along with the latest testing code.

http://www.phoronix.com/vr.php?view=20556

[Luke_Wolf]

So... other than for DES encryption, Ebizzy, TTSIOD 3D render, and timed MAAFT alignment the performance is more or less the same. Interesting. Anybody know what's up with those tests and whether it's a kernel or filesystem performance difference?

[0xBADCODE]

Rather strange set of benchmarks.

What is the point to do a bunch of some strange computational benchmarks which aren't depend too much on kernels without even trying to actually stress KERNEL? There was no single benchmark which would stress kernel. So it rather useless in sense we can't see how each kernel performs under same conditions, etc - most differences in test results were caused by anything else but different kernels. And it is logical to assume kernel can't harm computations too much unless doing something terminally wrong.

[Imroy]

This was more a comparison of compilers in Debian 7.5 vs 8.0 (i.e GCC 4.7 vs 4.8) than kFreeBSD vs Linux.

Why no filesystem benchmarks? Does PTS include benchmarks for forking/threading and networking? They would be interesting too.

[Marc Driftmeyer]

Seriously, what is stopping you from installing FreeBSD 10?

Better yet, wait until 10.1 when LLVM/Clang 3.5 with LLDB, Compiler-RT, etc are all interwoven.

That's the release I'm installing side-by-side Debian.

[enjolras]

Would be interesting to test network performance with various workload (with netperf), like TCP with vairous concurrent connection numbers, UDP with different packet sizes. Network performance is one selling point of Freebsd.

Also, dbench scalalibility is a good kernel stress test.

[schmidtbag]

Seriously, what is stopping you from installing FreeBSD 10?

Better yet, wait until 10.1 when LLVM/Clang 3.5 with LLDB, Compiler-RT, etc are all interwoven.

That's the release I'm installing side-by-side Debian.

You get a much more consistent environment and therefore consistent results when installing the same distro. I highly doubt debian is the best option for BSD but it's not the best linux option either. But, debian is one of the only distros that is relatively lean and fairly complete for both linux and BSD.

@0xBADCODE
And what do you propose to use as a test? You can go ahead and complain but your statement is nothing more than a personal opinion if you've got nothing to offer. Some of the tests still proved there are imperfections, so they weren't useless.

[Guest]

@0xBADCODE
And what do you propose to use as a test? You can go ahead and complain but your statement is nothing more than a personal opinion if you've got nothing to offer. Some of the tests still proved there are imperfections, so they weren't useless.

He's right. Didn't you notice compiler makes most of the difference here? Where's MySQL or other more meaningful benchmarks? There are imperfections, but it's nothing, but kernel configurations which doesn't show anything interesting here. Change scheduler latency and it will have impact on results.

[0xBADCODE]

You get a much more consistent environment and therefore consistent results when installing the same distro. I highly doubt debian is the best option for BSD but it's not the best linux option either. But, debian is one of the only distros that is relatively lean and fairly complete for both linux and BSD.

@0xBADCODE
And what do you propose to use as a test? You can go ahead and complain but your statement is nothing more than a personal opinion if you've got nothing to offer. Some of the tests still proved there are imperfections, so they weren't useless.

I think something kernel-heavy should be used for such tests. Some heavy networking? Filesystems usage? (though filesystems are mostly differ and it can be tricky, something common needed, like FATs or maybe ZFS). Intense use of syscalls? Say do millon fork()'s and measure time it takes.

The issue here is that computational tests do not stress kernel and rather depend on compiler, etc. Hence we can see results of misc. configuration differences (e.g. different compilers, etc) rather than anything else. So no useful conclusions could be made from such test. Okay, it shown that different compiler versions perform in different ways. It has been shown by previous tests ages ago so there is no new knowledge. And I fail to see how it relates to idea to test how Debian/kFreebsd performs vs Debian/GNU Linux. Seriously, this is most strange way I've seen to test and compare systems with different kernels as I fail to see anything which would be demanding to kernel.

[drSeehas]

This test is useless

What is the point to do a bunch of some strange computational benchmarks which aren't depend too much on kernels without even trying to actually stress KERNEL? There was no single benchmark which would stress kernel. So it rather useless in sense we can't see how each kernel performs under same conditions, ...

I fully agree.