FreeBSD 7.1 BETA 2 vs Opensolaris vs Ubuntu performance
Locked
12
12
 
|
|
|
|
|
|
|
In reply to this post by Steven Hartland
Steven Hartland wrote:
> http://www.phoronix.com/scan.php?page=article&item=os_threeway_2008&num=1 > > Was interesting until I saw this:- > The results seem well within expectations, for the sort of benchmarks they did: there is little difference between the systems. Depending on the details of how they did the benchmarks and how they processed the results (if at all), the results can even be within the margin of error (i.e. useless for mutual comparison except to show the systems are all very similar). The benchmarks they did are mostly focused on number crunching and do not even touch the area of system scalability to multiple CPUs, which could have been easily done but they chose not to. Number crunching is a bad choice for system scalability measure because down to the metal, all systems use similar compilers and there's nothing the OS can do to improve (or actually hinder, in the common case) CPU's execution of math code. For example, they could have included the "shells concurrent" benchmark from unixbench, started multiple bonnie++'s in parallel, and included a few system benchmarks like lighttpd+siege, parallel gzip (pigz) and blogbench. > "However, it's important to reiterate that all three operating systems > were left in their stock configurations and that no additional tweaking > had occurred." > > I kernel debugging stuff still enabled in FreeBSD 7.1 BETA 2, if so > these results are useless > and someone should contact the article writers to correct this. There is no debugging in -STABLE. WYSIWYG :) |
signature.asc (260 bytes)
|
|
|
|
|
|
|
|
Roman Divacky wrote:
> On Tue, Nov 25, 2008 at 12:08:27PM +0100, Ivan Voras wrote: >> Steven Hartland wrote: >>> http://www.phoronix.com/scan.php?page=article&item=os_threeway_2008&num=1 >>> >>> Was interesting until I saw this:- >>> >> The results seem well within expectations, for the sort of benchmarks >> they did: there is little difference between the systems. Depending on >> the details of how they did the benchmarks and how they processed the >> results (if at all), the results can even be within the margin of error >> (i.e. useless for mutual comparison except to show the systems are all >> very similar). >> >> The benchmarks they did are mostly focused on number crunching and do >> not even touch the area of system scalability to multiple CPUs, which >> could have been easily done but they chose not to. Number crunching is a >> bad choice for system scalability measure because down to the metal, all >> systems use similar compilers and there's nothing the OS can do to > > I believe most of the synthetic numbers (mp3 encoding etc.) difference > comes from the different version of gcc the different OS uses... the small difference in gzip and 7z compression performance. |
|
|
|
|
|
|
|
|
|
|
|
|
|
O. Hartmann wrote:
> Ivan Voras wrote: > ... > >> >> OTOH if the goal is to measure "operating system" performance, this >> must also include the compiler, libraries and all. (for example, what >> does Solaris default to nowadays? I think it ships with gcc but not as >> default). The hold on gcc 4.3 in FreeBSD is, after all, political >> (licencing). > > This is very bad to read :-( GPL 2). > Many of my colleaugues are involved in HPC, very little of them > (including myself) utilizing FreeBSD even due to the lack of fast > compilers. Yes, we all can use the port, that is right, but for those > not so familiar and deep inside the underlying OS, with newer, better > hardware (CPUs with some interesting hardware features like SSE3/4) a > on-track-following compiler like GCC 4.3 could make use of special > features introduced in newer hardware and even due to better > optimizations compile a faster OS. And the result, even in 3% or 5% > performance gain is appreciated if model-runs taking days or weeks! AFAIK, gcc 4.3+ will always be available in the ports so users that need it will always have it available (it's available there now!). It's just that the base compiler will either stay 4.2, switch to something else (Roman Divacky is working on LLVM+clang), or bite the bullet (with possible workarounds for undesireable parts of GPL3) and switch to a newer gcc. |
Loading...
| Powered by Nabble | Edit this page |