Page 10 of 11 FirstFirst ... 891011 LastLast
Results 91 to 100 of 107

Thread: A Big Operating System Benchmark Comparison

  1. #91
    Join Date
    Apr 2009
    Location
    Toronto/North Bay Canada
    Posts
    877

    Default

    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.

  2. #92
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,587

    Default

    Quote Originally Posted by L33F3R View Post
    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.
    Most old distro's would have a hissy fit with the newer hardware.

  3. #93
    Join Date
    Oct 2007
    Location
    UK
    Posts
    160

    Default

    Quote Originally Posted by L33F3R View Post
    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?

  4. #94

    Default

    Quote Originally Posted by vermaden View Post
    @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).


    Quote Originally Posted by vermaden
    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.

  5. #95
    Join Date
    Apr 2009
    Location
    Toronto/North Bay Canada
    Posts
    877

    Default

    Quote Originally Posted by lordmozilla View Post
    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.

  6. #96
    Join Date
    Jul 2009
    Posts
    3

    Default

    I would like to see Gentoo in this comparison.

  7. #97

    Default

    Quote Originally Posted by L33F3R View Post
    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.
    Last edited by kraftman; 08-21-2009 at 05:04 AM.

  8. #98
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,587

    Default

    Quote Originally Posted by kraftman View Post
    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).

  9. #99
    Join Date
    May 2008
    Posts
    55

    Default

    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.

  10. #100

    Default

    Quote Originally Posted by deanjo View Post
    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/L...edded-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.
    Last edited by kraftman; 08-21-2009 at 06:34 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •