Please add a little conclusion at the end of your articles, like "x wins for Ubuntu, y for FreeBSD and z equality, so ... <a little analysis>" . I don't want to read every benchmark in each article.
Phoronix: First Look: FreeBSD 9.0 On Intel Sandy Bridge
When recently having a ZaReason notebook in the office for Linux testing, the release candidate of PC-BSD/FreeBSD 9.0 was tested on this Intel Core i7 "Sandy Bridge" notebook and its performance compared to Ubuntu 11.10.
http://www.phoronix.com/vr.php?view=16707
Please add a little conclusion at the end of your articles, like "x wins for Ubuntu, y for FreeBSD and z equality, so ... <a little analysis>" . I don't want to read every benchmark in each article.
Out of general curiosity, could this be repeated with the same compiler on both? On freebsd, gcc4.6 is in ports (lang/gcc46), and then it should just be a case of setting CC/CXX .
Still comparing apples to oranges.
True, this time Linux won (unlike the previous Linux vs. FreeBSD benchmark), but the choice of Ubuntu (w/ Unity) vs. FreeBSD (w/ KDE) is border-line irrelevant. (FreeBSD might be getting hammered by background KDE processes.)
... On the other hand, people far smarter than me have been claiming for years that using self compiled packages (as opposed to disto packages whenever available) makes most of these benchmarks irrelevant.
- Gilboa
I would also like to see conclusions, it is one of the basics of writing. We don't always have time to read the full article, analyze and summarize ourselves.
Typically, I read the intro and jump straight to the conclusion. Then, when I feel a strong interest or want to check some details more deeply, I read the other pages.
So the lack of a few and clear words at the end is a big annoyance. Please add a "conclusions" section.
That should be a non-issue. None of this depends on X Windows, so the X Server could be off for these tests (not that Michael did that), but even with it on, the GUIs are simply idle and therefore inactive.
The principle difference in computational performance is GCC versus Clang. The disk performance is ext4 versus UFS. You have a poorly designed compiler that is fast simply because it has been around for decades against a well designed compiler that is slow because it is relatively new. At the same time, you have a file system which favors speed over data integrity against a filesystem which favors data integrity over speed.
Michael could have in theory recompiled FreeBSD with GCC and included it in the comparison and run these benchmarks with X windows on and off to allow for proper analysis, but he appears to be more interested in having sensationalist articles than having a valid testing methodology.
I couldn't disagree more.
On my two dual Xeon workstations, kwin eats ~3-9% CPU - even when the machine is idle.
Beyond that, KDE is running large number of background processes (e.g. Nepomuk, virtuoso-t which can easily eat 50-100% CPU while working) that must be manually disabled.
On the hand, at least in the 11.4, Unity was eating a lot CPU time while being idle.
All in all, both Unity and KDE may have considerable adverse effect on the benchmark results.
- Gilboa
This benchmark really crap, really unfair and gives bad impression to other party. Getting link-bait... popularity only...