A Big Operating System Benchmark Comparison

[lordmozilla]

what about a very very very very very old linux distro. One with a very very very very very old kernel. That would drastically show the linux evolution whether good or bad.

isnt that what ubuntu is for?

no seriously who cares? Just another fanboy so he can go "look linux is wicked we've improved 125% overall in all MYSQL benchmarks compared to 5 yrs ago!!!" seriously, how is that gonna be useful?

[T_Beermonster]

@T_Beermonster

HAMMER filesystem is not a ZFS rival or something like that, its developed to work in cluster environments.

I realise that it is not intended as a btrfsalike it is however intended to be the default filesystem for dragonflybsd, can be used locally (though intended for large partitions) and is now listed as production ready - so it should be part of the consideration in any benchmark of dragonflybsd (if the default filesystem cripples performance this should be allowed to show in the benchmarks just as much as if it enhamces performance).

Abou DragonflyBSD itself, it scales as FreeBSD 4.x (DragonflyBSD forked from FreeBSD 4.8) and works well only with single core CPUs, it does not use more then one core, its still big GIANT LOCK kernel.

Check these benchmarks below:

http://people.freebsd.org/~kris/scaling/dfly-mysql.png

http://people.freebsd.org/~kris/scaling/dfly-write.png

So adding DragonflyBSD to the test will not bring nothing new here, it is and will be slow, until they rewrite SMP subsystem as it has been done in FreeBSD 4.x --> 8.x

I'm afraid that the benchmark images you link to don't really tell me much. They relate to dragonflybsd 1.12 (feb 2008) and freebsd 7.0. Dragonflybsd is now at 2.2.1 (apr 2009).

Ultimately though I'm not interested in seeing a benchmark for dragonflybsd because I think it's wonderful and want to have my preconceived notions confirmed. I'm not trying to pick something that I think will "win" I'm just suggesting something I'd be interested in seeing, whether the results are good, bad or indifferent.
If performance really is terrible - all the more reason to include it.

[L33F3R]

isnt that what ubuntu is for?

no seriously who cares? Just another fanboy so he can go "look linux is wicked we've improved 125% overall in all MYSQL benchmarks compared to 5 yrs ago!!!" seriously, how is that gonna be useful?

thats assuming it has improved. The kernel is not always getting faster. Its becoming more and more bloated with every release.

[dummy]

I would like to see Gentoo in this comparison.

[kraftman]

thats assuming it has improved. The kernel is not always getting faster. Its becoming more and more bloated with every release.

Wrong. Tell me, why my kernel has the same size (+/- some bytes maybe) like previous kernels? You don't understand core kernel part almost (or just isn't) isn't growing. If they add something new it doesn't make it more bloated. You just have an option to use new features, file systems, drivers. Your choice. Don't base on archive size :> Btw. newer kernels are usually faster, but Phoronix benchmarks are meaningless in this case - they test distro defaults. Different compiler and programs versions, different kernel options, additional patches and programs which run in the background have influence on the results.

[deanjo]

Wrong. Tell me, why my kernel has the same size (+/- some bytes maybe) like previous kernels? You don't understand core kernel part almost (or just isn't) isn't growing. If they add something new it doesn't make it more bloated. You just have an option to use new features, file systems, drivers. Your choice. Don't base on archive size :> Btw. newer kernels are usually faster, but Phoronix benchmarks are meaningless in this case - they test distro defaults. Different compiler and programs versions, different kernel options, additional patches and programs which run in the background have influence on the results.

Well I'm not so sure about that. Tell me why 2.4 legacy kernels are still maintained and why so many embedded devices still use a 2.4 kernel (even newly introduced devices).

[LenS]

I was just reading this article which has some relevant info:

Source: Linux Kernel Development Speeds Up - InternetNews.com
Address : <http://www.internetnews.com/stats/article.php/3835286>
August 19, 2009
By Sean Michael Kerner: More stories by this author:

More developers are contributing more code to the development of Linux, and are speeding up in the process, according to a new study from the Linux Foundation.

The latest "Who Writes Linux" report is now its second year, tracking the development of Linux from the 2.6.24 kernel to the recent 2.6.30 kernel release.

The report found that that there Linux saw a net increase of 2.7 million lines of code between the 2.6.24 and 2.6.30 releases, compared to the almost 300,000 lines added in the run-up to 2.6.24.

That code was contributed to Linux at a faster rate and by more developers than the previous release, the report also found.

The pace of development, measured in terms of patches accepted every hour, was 42 percent faster than it had been in the first Who Writes Linux report. Between the 2.6.24 and the 2.6.30 releases, there were 5.45 patches accepted every hour, for an average of 10,923 lines of code added every day, the Foundation said.

New code contributions have included additional hardware support as well as operating system features such as next-generation filesystems like BTRFS.

While new code is added, old code is also pruned away. The report found that an average of 5,547 lines of code are removed every day.
Who is doing all the work?

Since the first Who Writes Linux report last year, the average number of individual developers who contribute to Linux has grown more than 10 percent: The 2.6.30 Linux kernel release had 1,150 developers while the 2.6.24 release had 1,057 developers.
Over the course of the last four and a half years, between the 2.6.11 kernel in 2005 and the 2.6.30 kernel release this year, a total of 4,190 individuals contributed.

But those figures don't tell the whole story, according to the Foundation.

"Despite the large number of individual developers, there is still a relatively small number who are doing the majority of the work," the report said. "In any given development cycle, approximately 1/3 of the developers involved contribute exactly one patch. Over the past 4.5 years, the top 10 individual developers have contributed almost 12 percent of the number of changes and the top 30 developers have contributed over 25 percent."

Surprisingly, Linux founder Linus Torvalds is no longer among the top 30 Linux contributors over the course of the last year, as measured by the total number of changes. Since the 2.6.24 kernel, Torvalds contributed 254 changes. In contrast, Red Hat kernel developer Ingo Molnar contributed 1,164 changes between the 2.6.24 and the 2.6.30 kernel releases.

"Linus remains an active and crucial part of the development process; his contribution cannot be measured just by the number of changes made," the report said.

Torvalds' contribution also can be seen in kernel merges. The report's patch contribution numbers do not count "merge commits," which is where the patch changes are merged into other changes in the Linux kernel. Since the 2.6.24 release, Torvalds directly managed 2.7 percent of all Linux kernel merges, ranking him ninth on the list of top developers that merged or signed-off on code for inclusion in Linux.
Top companies contributing

In terms of the top companies that contributed to the 2.6.30 release, Red Hat (NYSE: RHT) ranked No. 1, with 12 percent of all change contributions. IBM (NYSE: IBM) came in at second place with 6.3 percent, Novell (NASDAQ: NOVL) third at 6.1 percent and Intel (NASDAQ: INTC) fourth at 6.0 percent.

While developers with company affiliations contribute many changes to Linux, the report found that 21.1 percent of all changes since the 2.6.24 kernel came from developers with no corporate affiliation. In the previous study, the Linux Foundation reported only 13.9 percent of developers as having no corporate affiliation. At least part of the increase may come from simply improved data-collection.

"The increase in the number of developers with no employer is most likely an artifact of better information in our database -- many of them were previously in the 'unknown' category," the report said.

The 2008 report stated that developers whose corporate affiliation is unknown represented 12.9 percent of Linux kernel changes. In the new report, the unknowns now only represent 4.2 percent.

[kraftman]

Well I'm not so sure about that. Tell me why 2.4 legacy kernels are still maintained and why so many embedded devices still use a 2.4 kernel (even newly introduced devices).

I thought only about 2.6 series and about PC's. I have no idea why someone still wants to use 2.4 kernels

http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Linux-26-A-Breakthrough-for-Embedded-Systems/

Maybe they're less demanding on some devices? There's also possibility there are no reasons to migrate from 2.4 to 2.6 in some cases. Btw. 2.4 performance should be much worse then 2.6 on PC's etc.


Regarding to my previous comment:

The core of the Linux kernel is quite small, and it has also been surprisingly stable in recent times. The CPU scheduler has seen mostly incremental changes, and the core memory management code has seen few fundamental changes for years.

[Apopas]

I thought only about 2.6 series and about PC's. However, I have no idea why someone still wants to use 2.4 kernels

http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Linux-26-A-Breakthrough-for-Embedded-Systems/

Maybe they're less demanding on some devices? There's also possibility there are no reasons to migrate from 2.4 to 2.6. Btw. 2.4 performance should be much worse then 2.6 on PC's etc.

http://kerneltrap.org/Linux/Who_Uses_The_2.4_Stable_Kernel

the example I know personaly very well is DSL Linux which refuses to use kernel 2.6 because the image is a bit bigger.

[kraftman]

http://kerneltrap.org/Linux/Who_Uses..._Stable_Kernel

the example I know personaly very well is DSL Linux which refuses to use kernel 2.6 because the image is a bit bigger.

Oh yes. This is probably why 2.4 is chosen over 2.6 on some embedded systems.