Announcement

Collapse
No announcement yet.

DragonFlyBSD 3.0 Released With Multi-Core Boosts

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    *yawn*

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

    Comment


    • #3
      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; 23 February 2012, 12:45 AM.

      Comment


      • #4
        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).

        Comment


        • #5
          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.

          Comment

          Working...
          X