Results 1 to 5 of 5

Thread: DragonFlyBSD 3.0 Released With Multi-Core Boosts

  1. #1
    Join Date
    Jan 2007
    Posts
    14,240

    Default DragonFlyBSD 3.0 Released With Multi-Core Boosts

    Phoronix: DragonFlyBSD 3.0 Released With Multi-Core Boosts

    DragonflyBSD 3.0 was released today with major performance improvements for multi-core systems thanks to the recent VM SMP work, plus file-system performance improvements for HAMMER, and many other changes...

    http://www.phoronix.com/vr.php?view=MTA2MTE

  2. #2
    Join Date
    Sep 2008
    Posts
    989

    Default

    *yawn*

    Another BSD playing catch-up. Linux did this kind of basic multi-processor scalability work 5+ years ago.

  3. #3
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote Originally Posted by allquixotic View Post
    *yawn*

    Another BSD playing catch-up. Linux did this kind of basic multi-processor scalability work 5+ years ago.
    dont go knocking matt for playing catch up, he was providing FREE SOURCE before linux ever existed.

    well DragonFly is bit more than that, but i do wonder that Matt Dillon http://en.wikipedia.org/wiki/Matthew...ter_scientist) has lost his old amiga/DICE performance is everything edge way of thinking over the years, it would be nice if he got some of that innovative thinking back and pushed it faster in to today's DragonFly and related code/products, hell he could even make an ARM port blending of DragonFly and AROS in the old performance style, modernised for the ARM dual/quad future, now that could be fun to see.
    Last edited by popper; 02-22-2012 at 11:45 PM.

  4. #4
    Join Date
    Feb 2012
    Posts
    2

    Default

    Quote Originally Posted by popper View Post
    dont go knocking matt for playing catch up, he was providing FREE SOURCE before linux ever existed.

    well DragonFly is bit more than that, but i do wonder that Matt Dillon http://en.wikipedia.org/wiki/Matthew...ter_scientist) has lost his old amiga/DICE performance is everything edge way of thinking over the years, it would be nice if he got some of that innovative thinking back and pushed it faster in to today's DragonFly and related code/products, hell he could even make an ARM port blending of DragonFly and AROS in the old performance style, modernised for the ARM dual/quad future, now that could be fun to see.
    righto. Matt is a bright guy.

    as far as DragonflyBSD: it is maybe the last standing serious (may be, may be one can put Minix into the same category) attempt at systems programming innovation which is coming of the old unix tree. Check for example the HAMMER2 developments which are to be implemented (http://leaf.dragonflybsd.org/mailarc.../msg00020.html).

  5. #5
    Join Date
    Jan 2011
    Posts
    8

    Default

    Quote Originally Posted by allquixotic View Post
    *yawn*

    Another BSD playing catch-up. Linux did this kind of basic multi-processor scalability work 5+ years ago.
    DragonFly has taken an entirely different approach to scalability than Linux. Whereas Linux uses under most circumstances the typical blocking mutex model and in certain cases it does RCU, DragonFly is the only production-quality operating system out there that does not use the blocking mutex model as its primary locking strategy. Instead it uses something called a Soft Token which is released when the thread holding it blocks, this makes most DragonFly kernel code inherently deadlock-free. It may sound like a "basic" difference to you, but it is a fundamentally different model with huge ramifications on the design and subsequent performance and reliability of the resulting kernel. It also has huge ramifications in the area of code simplicity and understand-ability and as a result how productive kernel developers are in the near-term as well as how malleable the code is to substantial architectural changes over the long-term. All of this is important!

    Both kernels (and the other BSD's too) have many unique design traits and trade-offs, and for good reason. There are many things to account for beyond benchmark performance of a, b and c applications. Benchmarks don't really matter if you have poor interactive performance under load, or if certain kernel subsystems are prone to starvation, or you don't perform well in low memory situations, or...

    Seriously, you should be ashamed of making this comment -- not only are you spreading FUD but you are doing so while being totally ignorant of any of the truths of kernel architecture, there is nothing "basic" about it.

Posting Permissions

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