Phoronix FreeBSD 8 vs Ubunto 9.10

LLVM/Clang is still under heavy development; can it be trusted for such an important task? The license is right but what about its stability? GPLv3 should never have happened; there was nothing wrong with v2 but there is a whole slew of things wrong with v3. gcc 4.4 is a major step forward in gcc's evolution but its license is a major step backward. :( But anyways, if LLVM/Clang were to be considered production-quality across the board, then I think it would be worth seriously considering...I seem to remember it being previously used to build the FreeBSD kernel with some success.
 
Ubuntu 9.10 default kernel is tuned for desktop usage. FreeBSD by default targeted at Server usage. Also, I don't trust useless "Phoronix Test Suite". FreeBSD 7.x is the clear winner when it comes to stability and specifically the SMP engine. I'm working on large goverment project and RHEL 5.x failed to provide us stability and always had load issues. Now, all our servers are powered by FreeBSD and I had no issues since last 8-9 months. FreeBSD rocks. nuff said :D
 
Eponasoft said:
LLVM/Clang is still under heavy development; can it be trusted for such an important task? The license is right but what about its stability? GPLv3 should never have happened; there was nothing wrong with v2 but there is a whole slew of things wrong with v3. gcc 4.4 is a major step forward in gcc's evolution but its license is a major step backward. :( But anyways, if LLVM/Clang were to be considered production-quality across the board, then I think it would be worth seriously considering...I seem to remember it being previously used to build the FreeBSD kernel with some success.

clang's development team considers it to be a production-ready compiler for C and Obj-C, but not C++. As I recall, the core of FreeBSD doesn't contain any C++, which hopefully makes this less of an issue. gcc can't be excluded for quite a while yet, though.

clang also has some stunning advantages, that, frankly, make it nearly indispensable. not only does it help maintain excellent code quality, but the utility of clang is likely to help attract new contributors to the project. it's one of the biggest features i'm looking forward to over the next year, along with GCD.
 
oliverh said:
Why should someone care about it? Because e.g. gzip is faster in Ubuntu? What I do know: FreeBSD _is_ stable, FreeBSD doesn't need a plethora of updates week after week just to fix some of the primary bugs etc. For example, do you care about Povray? It's nice but lightyears behind present render-technologies. They're using multi-gpu technologies according to their changelog, is there maybe some impact on the performance while using a ATI-card (with fglrx driver) in Linux and some lousy free driver in FreeBSD? What are the compile-time options of the used applications and libraries, this is important: FreeBSD != Linux. There are lots of questions, but almost no answers just some numbers without any significance.

Construct a scenario that you do believe is correct and valid, and present it, work with Phoronix to get representative tests that show FreeBSD's value-adds and strengths. PTS is an open source suite, and Phoronix is more than welcome to accept tests.

Complaining is fine, but taking actions to improve is way more valuable.

Matt
 
vivek said:
Ubuntu 9.10 default kernel is tuned for desktop usage. FreeBSD by default targeted at Server usage. Also, I don't trust useless "Phoronix Test Suite". FreeBSD 7.x is the clear winner when it comes to stability and specifically the SMP engine. I'm working on large goverment project and RHEL 5.x failed to provide us stability and always had load issues. Now, all our servers are powered by FreeBSD and I had no issues since last 8-9 months. FreeBSD rocks. nuff said :D

Again, work with the Phoronix guys to construct a test that shows this. Construct a test that proves your assertion.

People can have personal preferences,

But people shouldn't make assertions "trust useless" benchmarking unless they are will to make sure that their assertions can be shown not to be "baseless".

Work with Phoronix to make FreeBSD shine.

Matt
 
mtippett said:
Again, work with the Phoronix guys to construct a test that shows this. Construct a test that proves your assertion.

People can have personal preferences,

But people shouldn't make assertions "trust useless" benchmarking unless they are will to make sure that their assertions can be shown not to be "baseless".

Work with Phoronix to make FreeBSD shine.

Matt

That doesn't make sense. Why would you work with them just to make the os look good on a benchmark that really doesn't have much to do with real world performance. I've USED both freebsd and ubuntu and what other people are saying in this thread is dead on. FreeBSD DOES work better under load. It's been shown time and time and time again that benchmarks can very unreliable when it comes to real world performance. It shows one very narrow "fact" but doesn't consider the real world.

Look at it like this: When you have different cars, and you have a 100 mile race, you could talk about top speeds all day long but it doesn't take into account how well the handle, if the driver is any good or whether or not there are any other things that might make it not perform well. Benchmarks are like this.
 
FreeBSD will always be at a disadvantage until the compiler situation is fixed. gcc 4.4, the default in modern linux distributions, provides an average of ~20% speedup (IIRC) over gcc 4.2, the default in FreeBSD (due to license issues).

While this is for the most part an issue with FreeBSD moreso than with the benchmarks (I think running the test suites from http://shootout.alioth.debian.org/ would be more useful, for what it's worth), it's worth pointing out that this is a compiler issue, not a kernel/libc issue. Someone running something that needs extremely high performance will probably use icc, which would eliminate compiler differences.

(Also ext4 is quicker than UFS2, but linux is going to get the best i/o performance with XFS, not ext4, and FreeBSD will get the best i/o performance with ZFS, not UFS2. Benchmarking i/o performance would ideally compare xfs and zfs, I figure. It'd also be useful to know if softupdates were enabled on UFS2 during the benchmark run [a default install will use softupdates on /usr and /var, but not on the root partition])
 
I've never been a major fan of benchmarks. They are useful to see how progress is made on the same platform, between versions...but the more variables you add to the equation, the less the benchmarks can really say. When you're talking about FreeBSD vs Linux and XFS vs ZFS vs UFS vs EXT4....whatever...it's just a TON of different things that can change the results. For my servers, i find freebsd to be more stable...i still use linux for some stuff (my xbmc htpc for example)

I guess each os has things that they excel in. I just don't put a lot of stock in these benchmarks....I like to try both myself and see which one works better for the job at hand.
 
irkkaaja said:
clang's development team considers it to be a production-ready compiler for C and Obj-C, but not C++. As I recall, the core of FreeBSD doesn't contain any C++.

There is some c++ code:

Code:
[/usr/src]% find . -name \*\\.cpp                                                                                                                       glitch:0:20
./contrib/groff/src/devices/grodvi/dvi.cpp
./contrib/groff/src/devices/grohtml/html-table.cpp
./contrib/groff/src/devices/grohtml/html-text.cpp
./contrib/groff/src/devices/grohtml/output.cpp
./contrib/groff/src/devices/grohtml/post-html.cpp
./contrib/groff/src/devices/grolbp/lbp.cpp
./contrib/groff/src/devices/grolj4/lj4.cpp
./contrib/groff/src/devices/grops/ps.cpp
./contrib/groff/src/devices/grops/psrm.cpp
./contrib/groff/src/devices/grotty/tty.cpp
./contrib/groff/src/libs/libbib/common.cpp
./contrib/groff/src/libs/libbib/index.cpp
./contrib/groff/src/libs/libbib/linear.cpp
./contrib/groff/src/libs/libbib/search.cpp
./contrib/groff/src/libs/libdriver/input.cpp
./contrib/groff/src/libs/libdriver/printer.cpp
./contrib/groff/src/libs/libgroff/assert.cpp
./contrib/groff/src/libs/libgroff/change_lf.cpp
./contrib/groff/src/libs/libgroff/cmap.cpp
./contrib/groff/src/libs/libgroff/color.cpp
./contrib/groff/src/libs/libgroff/cset.cpp
./contrib/groff/src/libs/libgroff/device.cpp
./contrib/groff/src/libs/libgroff/errarg.cpp
./contrib/groff/src/libs/libgroff/error.cpp
./contrib/groff/src/libs/libgroff/fatal.cpp
./contrib/groff/src/libs/libgroff/filename.cpp
./contrib/groff/src/libs/libgroff/font.cpp
./contrib/groff/src/libs/libgroff/fontfile.cpp
./contrib/groff/src/libs/libgroff/geometry.cpp
./contrib/groff/src/libs/libgroff/glyphuni.cpp
./contrib/groff/src/libs/libgroff/htmlhint.cpp
./contrib/groff/src/libs/libgroff/hypot.cpp
./contrib/groff/src/libs/libgroff/invalid.cpp
./contrib/groff/src/libs/libgroff/lf.cpp
./contrib/groff/src/libs/libgroff/lineno.cpp
./contrib/groff/src/libs/libgroff/macropath.cpp
./contrib/groff/src/libs/libgroff/maxfilename.cpp
./contrib/groff/src/libs/libgroff/maxpathname.cpp
./contrib/groff/src/libs/libgroff/mksdir.cpp
./contrib/groff/src/libs/libgroff/mkstemp.cpp
./contrib/groff/src/libs/libgroff/nametoindex.cpp
./contrib/groff/src/libs/libgroff/new.cpp
./contrib/groff/src/libs/libgroff/paper.cpp
./contrib/groff/src/libs/libgroff/prime.cpp
./contrib/groff/src/libs/libgroff/ptable.cpp
./contrib/groff/src/libs/libgroff/relocate.cpp
./contrib/groff/src/libs/libgroff/searchpath.cpp
./contrib/groff/src/libs/libgroff/string.cpp
./contrib/groff/src/libs/libgroff/strsave.cpp
./contrib/groff/src/libs/libgroff/symbol.cpp
./contrib/groff/src/libs/libgroff/tmpfile.cpp
./contrib/groff/src/libs/libgroff/tmpname.cpp
./contrib/groff/src/libs/libgroff/unicode.cpp
./contrib/groff/src/libs/libgroff/uniglyph.cpp
./contrib/groff/src/libs/libgroff/uniuni.cpp
./contrib/groff/src/preproc/eqn/box.cpp
./contrib/groff/src/preproc/eqn/delim.cpp
./contrib/groff/src/preproc/eqn/lex.cpp
./contrib/groff/src/preproc/eqn/limit.cpp
./contrib/groff/src/preproc/eqn/list.cpp
./contrib/groff/src/preproc/eqn/main.cpp
./contrib/groff/src/preproc/eqn/mark.cpp
./contrib/groff/src/preproc/eqn/other.cpp
./contrib/groff/src/preproc/eqn/over.cpp
./contrib/groff/src/preproc/eqn/pile.cpp
./contrib/groff/src/preproc/eqn/script.cpp
./contrib/groff/src/preproc/eqn/special.cpp
./contrib/groff/src/preproc/eqn/sqrt.cpp
./contrib/groff/src/preproc/eqn/text.cpp
./contrib/groff/src/preproc/grn/hdb.cpp
./contrib/groff/src/preproc/grn/hgraph.cpp
./contrib/groff/src/preproc/grn/hpoint.cpp
./contrib/groff/src/preproc/grn/main.cpp
./contrib/groff/src/preproc/html/pre-html.cpp
./contrib/groff/src/preproc/html/pushback.cpp
./contrib/groff/src/preproc/pic/common.cpp
./contrib/groff/src/preproc/pic/lex.cpp
./contrib/groff/src/preproc/pic/main.cpp
./contrib/groff/src/preproc/pic/object.cpp
./contrib/groff/src/preproc/pic/tex.cpp
./contrib/groff/src/preproc/pic/troff.cpp
./contrib/groff/src/preproc/refer/command.cpp
./contrib/groff/src/preproc/refer/ref.cpp
./contrib/groff/src/preproc/refer/refer.cpp
./contrib/groff/src/preproc/refer/token.cpp
./contrib/groff/src/preproc/soelim/soelim.cpp
./contrib/groff/src/preproc/tbl/main.cpp
./contrib/groff/src/preproc/tbl/table.cpp
./contrib/groff/src/roff/groff/groff.cpp
./contrib/groff/src/roff/troff/column.cpp
./contrib/groff/src/roff/troff/dictionary.cpp
./contrib/groff/src/roff/troff/div.cpp
./contrib/groff/src/roff/troff/env.cpp
./contrib/groff/src/roff/troff/input.cpp
./contrib/groff/src/roff/troff/mtsm.cpp
./contrib/groff/src/roff/troff/node.cpp
./contrib/groff/src/roff/troff/number.cpp
./contrib/groff/src/roff/troff/reg.cpp
./contrib/groff/src/utils/addftinfo/addftinfo.cpp
./contrib/groff/src/utils/addftinfo/guess.cpp
./contrib/groff/src/utils/hpftodit/hpftodit.cpp
./contrib/groff/src/utils/hpftodit/hpuni.cpp
./contrib/groff/src/utils/indxbib/indxbib.cpp
./contrib/groff/src/utils/lkbib/lkbib.cpp
./contrib/groff/src/utils/lookbib/lookbib.cpp
./contrib/groff/src/utils/tfmtodit/tfmtodit.cpp
./contrib/wpa_supplicant/wpa_gui/main.cpp
./contrib/wpa_supplicant/wpa_gui-qt4/eventhistory.cpp
./contrib/wpa_supplicant/wpa_gui-qt4/main.cpp
./contrib/wpa_supplicant/wpa_gui-qt4/networkconfig.cpp
./contrib/wpa_supplicant/wpa_gui-qt4/scanresults.cpp
./contrib/wpa_supplicant/wpa_gui-qt4/userdatarequest.cpp
./contrib/wpa_supplicant/wpa_gui-qt4/wpagui.cpp
./crypto/openssl/crypto/bf/bfs.cpp
./crypto/openssl/crypto/cast/casts.cpp
./crypto/openssl/crypto/des/des3s.cpp
./crypto/openssl/crypto/des/dess.cpp
./crypto/openssl/crypto/md4/md4s.cpp
./crypto/openssl/crypto/md5/md5s.cpp
./crypto/openssl/crypto/rc4/rc4s.cpp
./crypto/openssl/crypto/rc5/rc5s.cpp
./crypto/openssl/crypto/ripemd/asm/rips.cpp
./crypto/openssl/crypto/sha/sha1s.cpp
./crypto/openssl/demos/ssl/cli.cpp
./crypto/openssl/demos/ssl/inetdsrv.cpp
./crypto/openssl/demos/ssl/serv.cpp
./crypto/openssl/times/x86/bfs.cpp
./crypto/openssl/times/x86/casts.cpp
./crypto/openssl/times/x86/des3s.cpp
./crypto/openssl/times/x86/dess.cpp
./crypto/openssl/times/x86/md4s.cpp
./crypto/openssl/times/x86/md5s.cpp
./crypto/openssl/times/x86/rc4s.cpp
./crypto/openssl/times/x86/sha1s.cpp
 
irkkaaja said:
Someone running something that needs extremely high performance will probably use icc, which would eliminate compiler differences.
Yes, I think I might go through the effort of getting a copy of it. IIRC it is free for non-commercial use provided you have the patience to jump through all the hoops required to download it.

irkkaaja said:
(Also ext4 is quicker than UFS2
Is it really? Keep in mind that ext4 does full journaling out the box, and I suspect is written asynchronously too. UFS's soft updates only journals meta data out the box and writes are consequently synchronous. If gjournal is enabled and the file systems are mounted async, there should be a considerable speed improvement.
 
It would be interesting a benchmark test for FreeBSD 7.2 and 8.0, with default gcc, and with gcc 4.5 from ports, only for the sake of benchmarks :).
 
aragon said:
Is it really? Keep in mind that ext4 does full journaling out the box, and I suspect is written asynchronously too. UFS's soft updates only journals meta data out the box and writes are consequently synchronous. If gjournal is enabled and the file systems are mounted async, there should be a considerable speed improvement.

ext4 is indeed written asynchronously. In fact, it's the first of the ext* to perform asynchronouus writes by default, which has caused considerable controversy in the linux world. In addition, if Phoronix tested i/o performance on / rather than /usr or /var, softupdates would have been disabled, as sysinstall enables softupdates by default on every partition but / (you shouldn't be writing to / anyway, really). Phoronix usually tests things on the default settings, so they kind of compared different filesystem settings more than they compared different filesystems. On a tangent, I think it'd be interesting to see (for freebsd 9?) a resource-light copy-on-write filesystem as a successor to UFS2 for applications where ZFS is inappropriate.

If I might ask, what compiler options are used to compile the kernel? I've heard that in post-4.0 versions of gcc, -Os can sometimes be faster than -O2 or -O3, thanks to improved instruction cache optimization, which seems relevant in a thread about performance.
 
That said, gcc is stinky. Stinky! Stinky!

irkkaaja said:
If I might ask, what compiler options are used to compile the kernel? I've heard that in post-4.0 versions of gcc, -Os can sometimes be faster than -O2 or -O3, thanks to improved instruction cache optimization, which seems relevant in a thread about performance.

I believe the default is -O2 -pipe -fomit-frame-pointer (but I could be mistaken & I don't recall where to find that).

Also, last time I tried (early February?) -Os built a broken kernel on 8.x. I don't know that that's true now, but I also don't care to test.

-O3 has been sketchy for me in the past as well.
 
Back
Top