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.

In *BSD world everyone have to reinvent wheel again. Just because competitor wants to slow all "enemies" down and outrun them. So everyone reinvents the wheel. In Linux world, wheel invented once and then similar bunch of people improves it instead of parallel re-invention of the same thing. Seems to give quite an obvious results.

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!

The OpenSSL result is particularly interesting. But I couldn't reproduce it on my own (AMD Opteron) systems. Using latest Debian 1.0.1c-3 packages, I ran 'openssl speed' which includes an RSA 4096-bit signing benchmark. The other output from this command (compile options) is helpful to see if trying to compare benchmarks. A 2.6GHz Opteron 285 (twin, dual-core) system with Linux 2.6.32 scored 73.7 sign/s whereas a 2.2GHz Opteron 248 (single, dual-core) GNU/kFreeBSD system (9.0-1-amd64 kernel) scored 62.1 sign/s. I assume the benchmark runs on a single core and thus these results are almost precisely in-line with the relative clock speeds. Certainly no 4x performance reduction seen.

I don't know how the benchmark for PTS works, but I'm curious why the test result panel says "OpenSSL 1.0.0e" which is not the (recently) packaged Debian version.

Otherwise, I'd guess the cause of this is something hardware-specific, with this particular CPU not reaching full performance under this FreeBSD kernel version. I would check for anything related to CPU scaling, power draw (which is nice to see in many Phoronix benchmarks), or otherwise see if FreeBSD have already made any changes in HEAD / kfreebsd-10 relating to this hardware.

If BSD is so much slower than Linux, how did that article a while back come about that showed BSD was faster at running native Linux games?

It was explained. BSD was running KDE with suspended compositions and was tested against Ubuntu which is using compiz and has this option disabled. So it was KDE that was faster than compiz in this tests.

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...

Damn troll. It has many real file systems unlike others. Who cares about your configuration?

The OpenSSL result is particularly interesting. But I couldn't reproduce it on my own (AMD Opteron) systems. Using latest Debian 1.0.1c-3 packages, I ran 'openssl speed' which includes an RSA 4096-bit signing benchmark. The other output from this command (compile options) is helpful to see if trying to compare benchmarks. A 2.6GHz Opteron 285 (twin, dual-core) system with Linux 2.6.32 scored 73.7 sign/s whereas a 2.2GHz Opteron 248 (single, dual-core) GNU/kFreeBSD system (9.0-1-amd64 kernel) scored 62.1 sign/s. I assume the benchmark runs on a single core and thus these results are almost precisely in-line with the relative clock speeds. Certainly no 4x performance reduction seen.

I don't know how the benchmark for PTS works, but I'm curious why the test result panel says "OpenSSL 1.0.0e" which is not the (recently) packaged Debian version.

Otherwise, I'd guess the cause of this is something hardware-specific, with this particular CPU not reaching full performance under this FreeBSD kernel version. I would check for anything related to CPU scaling, power draw (which is nice to see in many Phoronix benchmarks), or otherwise see if FreeBSD have already made any changes in HEAD / kfreebsd-10 relating to this hardware.

The case is not hardware, but BSD and... date specific. Aren't you aware you tested few year old Linux kernel while there's much newer one used in Phoronix comparison?

The case is not hardware, but BSD and... date specific. Aren't you aware you tested few year old Linux kernel while there's much newer one used in Phoronix comparison?

I'm aware that I used a much older Linux kernel for my quick test, but I don't expect that would make much difference. I don't imagine Linux 2.6.32 -> 3.2.x would make it 4x faster and thus bring it in line with the Phoronix result.

If I get the opportunity, I may try to do this properly (Linux 3.2.x vs. GNU/kFreeBSD 9.0, and use the same machine for both tests).

I'm also curious how the Phoronix OpenSSL result compares with 'openssl speed', in case it is a problem in the test suite. Perhaps it used all 4 cores on Linux but on BSD may not be detecting the number of cores correctly (the numbers would make sense).

I'm aware that I used a much older Linux kernel for my quick test, but I don't expect that would make much difference. I don't imagine Linux 2.6.32 -> 3.2.x would make it 4x faster and thus bring it in line with the Phoronix result.

Well 2.6.32 was released in december 2009 so I'd say it's very old by kernel standards and there's every reason to believe there's been alot of optimizations since then. That said I think a 4 x difference in performance is suspiciously extreme (although it was only one test where it was this extreme iirc), and while I'm not surprised Linux performs better than FreeBSD/PC-BSD I'd expect it to be much closer.

I'm also curious how the Phoronix OpenSSL result compares with 'openssl speed', in case it is a problem in the test suite. Perhaps it used all 4 cores on Linux but on BSD may not be detecting the number of cores correctly (the numbers would make sense).

"openssl speed rsa4096" is a single-threaded test, and ~40 is a completely normal result. For reference my phenom does ~58.

I think the results are unusual, especially the OpenSSL results. You should check for interrupt storms (vmstat -i?) and check that the CPU is really running at full steam. I've seen weird quirks where booting FreeBSD from battery causes the processor to be stuck in a power-saving state and running at reduced clock speed (even if you plug it back in).

Also suspect is SCHED_ULE ... this new scheduler was designed to ensure interactive application responsiveness under load. You could try changing it to SCHED_4BSD, however, that's not how GENERIC is shipped.

Lastly, FreeBSD is stuck at gcc 4.2 while the newer Linux distributions are using later versions of gcc. Maybe these later versions are better at optimization? Shouldn't, for example, John the Ripper run about the same on FreeBSD? Why should the same blowfish implementation be slower on FreeBSD? That shouldn't involve FreeBSD at all. You can compile all ports in FreeBSD with the same version of gcc by first building the same version of gcc from ports and then exporting CC and CXX and then building benchmark applications from ports the usual way.

Lastly, missing from all benchmarks on phoronix is significance levels. Significance should be measured overall and pairwise. The former measures if the overall timing difference is significant while the latter measures significance in consistency. For example, one test may not be significant overall, but be significantly consistently better/faster/etc. Tests should probably also consider a "warm-up" period to discard fluke speed-ups or slow-downs (if not already).