# Phoronix FreeBSD 8 vs Ubunto 9.10



## tbyte (Sep 28, 2009)

I just saw a new article on Phoronix testing the performance of FreeBSD 8.0 vs Ubunto 9.10.
I think a lot of the tests are influenced by the difference of gcc compilator versions that are used - 4.2.1 for FreeBSD (pretty old already) and 4.4.1 for Ubuntu. But I don't think that memory and threads tests have anything to do with the gcc version difference thou


----------



## SirDice (Sep 28, 2009)

IIRC 8.0 (and 7.2 too) still have quite a lot of debugging options turned on by default. I wonder how the figures would be when they're turned off.


----------



## DutchDaemon (Sep 28, 2009)

I was wondering about that too. If they have WITNESS and other stuff on, the comparison is totally false.


----------



## tbyte (Sep 28, 2009)

I don't think WITNESS or DEBUG are in the 7.2 stock kernel


----------



## DutchDaemon (Sep 28, 2009)

DEBUG=-g, KTRACE and AUDIT are in the 7.2 kernel, and on by default. Then again, I have no idea about the kind of stuff that's in the linux kernel and on by default.


----------



## SirDice (Sep 28, 2009)

tbyte said:
			
		

> I don't think WITNESS or DEBUG are in the 7.2 stock kernel



DEBUG is, WITNESS isn't.


----------



## DutchDaemon (Sep 28, 2009)

I have to add: starting with RC, FreeBSD 8 appears to have dropped WITNESS and other debugging, so the 7.2 and 8.0-RC kernel contain roughly the same defaults.

The article was slahdotted: http://linux.slashdot.org/story/09/09/28/127241/FreeBSD-80-vs-Ubuntu-910-Benchmarks, so comments there may provide more detail over time.


----------



## foldingstock (Sep 28, 2009)

Maybe I am missing something, but what is the point of comparing FreeBSD with Ubuntu? The two projects have completely different goals and are usually used for very different tasks. 

I suppose some people have to much free time and need the ad revenue.


----------



## oliverh (Sep 28, 2009)

I don't see any use of such benchmarks. There is some gzip, some lame, an aged byte benchmark etc., Povray. I would like to see the state of the art render engine Yafray, h264 and aac encoding instead of mp3, bzip2 instead of gzip etc. pp. And there you see the problem: a benchmark is a very personal point of view.


----------



## overmind (Sep 28, 2009)

There is another thing: on an dual core ubuntu laptop if I have a load bigger than 2, the sistem responds very slow. With FreeBSD I have immediate response when I launch an app, there is a very big difference. 

I have FreeBSD 8.0 RC1, I've read that debug is not compiled but from time to time I have detailed messages on console, and it seems like kernel debug messages.


```
lock order reversal:
 1st 0xc6b81df4 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_syscalls.c:4096
 2nd 0xc0e0be7c allproc (allproc) @
/usr/src/sys/fs/pseudofs/pseudofs_vnops.c:757
KDB: stack backtrace:
db_trace_self_wrapper(c0cb94c3,e710aaf0,c09029f5,c08f377b,c0cbc396,...) at 
db_trace_self_wrapper+0x26
kdb_backtrace(c08f377b,c0cbc396,c45305a8,c45280d0,e710ab4c,...) at 
kdb_backtrace+0x29
_witness_debugger(c0cbc396,c0e0be7c,c0cb549d,c45280d0,c0cac20d,...) at _witness_debugger+0x25
witness_checkorder(c0e0be7c,1,c0cac20d,2f5,0,...) at witness_checkorder+0x839
_sx_slock(c0e0be7c,0,c0cac20d,2f5,c4ae7500,...) at _sx_slock+0x85
pfs_readdir(e710ac20,0,c6b81d9c,0,e710ac58,...) at pfs_readdir+0x131
VOP_READDIR_APV(c0d99080,e710ac20,c0cc4670,1000,1000,...) at VOP_READDIR_APV+0xa5
kern_getdirentries(c8c78900,4,2839f000,1000,e710ac74,...) at kern_getdirentries+0x214
getdirentries(c8c78900,e710acf8,10,c0cbd05e,c0d9cd50,...) at getdirentries+0x31
syscall(e710ad38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
```


```
laptop# uname -a
FreeBSD laptop 8.0-RC1 FreeBSD 8.0-RC1 #0: Mon Sep 21 17:41:07 EEST 2009
ov@laptop:/usr/obj/usr/src/sys/LAPTOP  i386
```

Mystery solved: I have 8.0 RC1 but config file was from 8.0Beta.

You're right guys, only DEBUG=-g in 8.0RC1.

Can I remove DEBUG=-g line?


----------



## aragon (Sep 28, 2009)

Yep, not a perfect test really, and I posted my 2c in the article's discussion thread (on phoronix, not slashdot).


----------



## richardpl (Sep 28, 2009)

overmind said:
			
		

> There is another thing: on an dual core ubuntu laptop if I have a load bigger than 2, the sistem responds very slow. With FreeBSD I have immediate response when I launch an app, there is a very big difference.
> 
> I have FreeBSD 8.0 RC1, I've read that debug is not compiled but from time to time I have detailed messages on console, and it seems like kernel debug messages.
> 
> ...



You have WITNESS enabled (because of lor message)


----------



## phospher (Sep 28, 2009)

linux is a respectable operating system but that article is quite the contrary. as we all know, they are comparing apples to oranges. nuff said.


----------



## Eponasoft (Sep 29, 2009)

Those tests are subjective as hell and it is clear as day to see which ones are relying on clean code rather than debug code. It is blatantly obvious that the performance "issues" are caused by debug code running; lots of bounds checking, etc. especially with the memory testing. Why not run a proper test with both operating systems at max performance? Or better yet, skip the testing altogether because in reality, no one really gives a rat about these benchmarks except (1) uber-geeks and (2) people trying to sell a product.


----------



## wonslung (Sep 29, 2009)

Personally, i find ubuntu to be terrible under load.  I'm not a programmer so i have no idea why, but similar applications, especially network based ones, really seem to run better, and at lower load on FreeBSD.

But what's more, even when the system DOES get loaded, you can still enter commands...This is just not true for me on ubuntu.  The only thing i use ubuntu for anymore is my xbmc htpc's, and as soon as someone gets xbmc with vdpau working well on freebsd, I'm sure i'll end up switching those boxes as well.


----------



## irkkaaja (Sep 29, 2009)

DutchDaemon said:
			
		

> DEBUG=-g, KTRACE and AUDIT are in the 7.2 kernel, and on by default. Then again, I have no idea about the kind of stuff that's in the linux kernel and on by default.



Isn't it kind of a hindrance to end users to enable DEBUG -g in a final version release?


----------



## SirDice (Sep 29, 2009)

irkkaaja said:
			
		

> Isn't it kind of a hindrance to end users to enable DEBUG -g in a final version release?



Most users probably won't notice and it'll help finding where a bug occurs. More 'advanced' users compile their own kernel anyway.


----------



## tbyte (Sep 29, 2009)

irkkaaja said:
			
		

> Isn't it kind of a hindrance to end users to enable DEBUG -g in a final version release?


-g doesn't hinder performance. Debug info is kept in separate file and only loaded when debugging.


----------



## mtippett (Sep 29, 2009)

Hi all,

Please look at 

http://phoronix.com/forums/showthread.php?p=94222#post94222

In particular the debug code status.  ie: RC-1 was used, and the debugging code was turned off.

I am truly interested in seeing any further views about the testing on the thread.

Regards,

Matthew


----------



## oliverh (Sep 29, 2009)

irkkaaja said:
			
		

> Isn't it kind of a hindrance to end users to enable DEBUG -g in a final version release?



>Bad: Kernel build times are now significantly slower, and required space to build a kernel significantly larger by default.

http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2005-11/1404.html

There is no performance loss while using the kernel.


----------



## oliverh (Sep 29, 2009)

mtippett said:
			
		

> Hi all,
> 
> Please look at
> 
> ...



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.


----------



## everypot (Sep 29, 2009)

now it's time to replace gcc with LLVM/Clang.


----------



## SirDice (Sep 29, 2009)

oliverh said:
			
		

> There are lots of questions, but almost no answers just some numbers without any significance.


And the numbers are pretty hard to read. As someone on Slashdot noted, the graphs are gray on gray. For some lower is beter, others higher. It's bloody hard to read in any case. The guy that created them must be seriously colorblind.

Not that I really care about those numbers anyway. I'm not even considering trading in my beautiful FreeBSD desktop and servers for that horrible piece of #@%^#$@# called Ubuntu x(


----------



## Eponasoft (Sep 30, 2009)

everypot said:
			
		

> now it's time to replace gcc with LLVM/Clang.


No way...


----------



## irkkaaja (Sep 30, 2009)

Eponasoft said:
			
		

> No way...



What? Why not?

FreeBSD has been using an outdated version of gcc by default ever since the switch to GPLv3. Both gcc 4.4 and llvm produce significantly faster code than gcc 4.2, which we're currently using, and that's not to mention that the GPLv2 variant of gcc is essentally no longer maintained. Look at this:

http://multimedia.cx/eggs/icc-vs-gcc-smackdown-round-3/

gcc 4.4 is _way_ faster than gcc 4.2. We won't see any improvements like that until we start using a compiler that's actively developed, be it clang or open64.


----------



## Eponasoft (Sep 30, 2009)

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.


----------



## vivek (Sep 30, 2009)

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


----------



## irkkaaja (Oct 1, 2009)

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.


----------



## mtippett (Oct 1, 2009)

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


----------



## mtippett (Oct 1, 2009)

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



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


----------



## wonslung (Oct 1, 2009)

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



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.


----------



## irkkaaja (Oct 1, 2009)

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])


----------



## wonslung (Oct 1, 2009)

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.


----------



## Carpetsmoker (Oct 1, 2009)

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:


```
[/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
```


----------



## aragon (Oct 2, 2009)

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.


----------



## overmind (Oct 2, 2009)

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 .


----------



## irkkaaja (Oct 2, 2009)

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.


----------



## fronclynne (Oct 5, 2009)

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


----------

