Date: Fri, 29 Jun 2012 13:10:01 +0200 (CEST) From: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> To: Julien Cigar <jcigar@ulb.ac.be> Cc: freebsd-questions@freebsd.org Subject: Re: Anatomy of Perfomance tests Message-ID: <alpine.BSF.2.00.1206291302410.44321@wojtek.tensor.gdynia.pl> In-Reply-To: <4FED7815.10102@ulb.ac.be> References: <CAKdykDsWhygQz21R=wX8ou70Wd6GnV5SZ%2BNA8AFSDOY69-zikQ@mail.gmail.com> <alpine.BSF.2.00.1206291046510.43578@wojtek.tensor.gdynia.pl> <CAH3a3KVnw-CWCii1NdMAi8xuOZsvvN7Btd53xqJh4jMYhOL3Og@mail.gmail.com> <4FED7815.10102@ulb.ac.be>
next in thread | previous in thread | raw e-mail | index | archive | help
>> That said, I think that the Linux kernel performs better simply due to >> wider adoption (larger developer base, wider set of use-cases, etc) >> and thus a higher chance of getting performance improvements. > > Note that stability matters too. of course - this is what i pointed out at first. the second is clear team managing a kernel, and support. What i recently get when getting FreeBSD crash problems is something that you'll not get from linux. It found out to be my fault. I would generally call properly configured FreeBSD as rock-stable. The filesystem performance was close, and comparing dangerous linux filesystem to UFS isn't good. i would recommend comparing -o async mounted UFS with that test. Second - i would like to see how responsive linux server is WHILE performing that tests ;) high latencies under load was a problem i always had with linux when still using it. But scientific computing task results are FreeBSD fault, and the some reason is clang compiler,. With recent gcc-recompiled binaries it would be similar result. Similar as with compute-bound processes OS doesn't have much to change. Maybe, if there were more threads run than available, scheduler could matter. And i think FreeBSD scheduler would clearly win.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1206291302410.44321>