Announcement

Collapse
No announcement yet.

DragonFlyBSD Improves Performance Against Linux

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

  • DragonFlyBSD Improves Performance Against Linux

    Phoronix: DragonFlyBSD Improves Performance Against Linux

    Benchmarks coming out of the BSD camp are showing that the soon-to-be-released DragonFlyBSD 3.2 is almost as fast as Scientific Linux (RHEL) 6.2 in at least one real-world workload...

    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
    So they came in second to an aging Enterprise Linux distribution and didn't even use the current version of that... but I'll let that slide because......FreeBSD....and NetBSD.. . ouch.

    I know their performance is bad (partially because they hate the GPL 3 imposing all of that horrible Freedom and don't want to use a recent version of GCC), but I didn't know it had decayed to this point.

    Comment


    • #3
      Disclaimer: I am a df dev.

      """
      Originally posted by DaemonFC View Post
      So they came in second to an aging Enterprise Linux distribution and didn't even use the current version of that... but I'll let that slide because......FreeBSD....and NetBSD.. . ouch.
      """


      Scientific linux is based on RHEL - which also means that kernel/c library etc. versions are almost identical from release to release. So 6.2.x vs 6.3.x is practically irrelevant.

      And how is this "aging" since it is the latest one? Or are you saying that the test should have picked a non-enterprise distribution in general, like fedora or ubuntu or something?


      """
      I know their performance is bad (partially because they hate the GPL 3 imposing all of that horrible Freedom and don't want to use a recent version of GCC), but I didn't know it had decayed to this point.
      """

      This statement is just incorrect in so many ways. Due to the high level of parallelism in the test (many core machines), this is less
      of a indicator of 'performance decaying' as 'how far the different systems have advanced to take advantage of SMP & chip level SMT, etc'
      recall at one point, they did not support these things, and have all required major modifications (aka years of hard work) by all involved
      to get to their respective levels of advancement at present, with much to go for all involved.

      And being a database test, this has much more to do with scheduler algorithms, IO and virtual memory subsystems etc. than compiler optimization - eg. the test is system/IO/memory bound, and not compute bound, so compiler is less of a factor.

      The benchmarking was initially prompted by a major change in how postgres handles its memory structures - a change which
      has an extremely negative impact on how many unix virtual memory systems have traditionally been implemented - aka
      a questionable change to make - and some of the other non-dragonfly OS's have not been adapted to cope with this.
      This was a very recent change in postgres, so that is not a 'omg bsds are so old and not shiny' thing. So while it is good to
      see dragonfly competitive with Linux, this should be kept in mind. IIRC FreeBSD had a different workaround to avoid this problem
      but not 100%.

      R.e. GCC: firstly: dragonfly uses GCC4.4 - which is the same GCC major release as in RHEL6.. and 4.7 has been imported to switch
      over after this release. Also - performance tests indicate that clang (which FreeBSD will be switching to in 10.x) - is superior to gcc
      in some performance tests, but slower in others - so in other words, they are extermely competitive:

      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


      So really, I'm not sure what your compiler / gpl3 statements are in reference to here.

      Comment


      • #4
        Yes you're right. Linux rox, and has no scalability issue, it's well known. And postgresql scales easily on latest linux kernels. Oh wait !
        http://http://lwn.net/Articles/518329/

        Comment


        • #5
          I am curious to know... would a DragonFly vkernel be able to run in user land of another OS? It is considered similar to UML but I wonder if it also could be used similarly to coLinux.

          A "coBSD" kernel (or a BSD syscall compatibility module for the Linux kernel) would be fun to play with on a Linux host (or perhaps am I rather alone in this) - especially the theoretical posibility to be able to run a BSD system in a chroot on a Linux host without full virtualization.

          Comment


          • #6
            "
            [QUOTE=staalmannen;290857]I am curious to know... would a DragonFly vkernel be able to run in user land of another OS? It is considered similar to UML but I wonder if it also could be used similarly to coLinux.
            "

            The vkernel requires some host-side support - specifically ability to create 'vmspaces' which are separate virtual memory maps,
            and also a some minor hooks to interface to hardware / host side resources. Doable, but alot of work. Someone interested in knowing
            this level of detail would be better of giving DF hardware assisted virtualization so you could run DF and virtualize the 'other' os where
            needed

            UML iirc also required same.

            Probably the best bet right now to run dragonfly on another OS is virtualization e.g. via KVM / QEMU / VirtualBox.
            I am personally, other than on several native dragonfly machines, running df on VirtualBox/Linux, with some devs using KVM.

            Comment


            • #7
              Nice to see dragonfly bsd doing well, I have been watching it for years.

              Comment


              • #8
                So DragonFlyBSD is very interesting and definitely not a waste of time...

                Comment


                • #9
                  [QUOTE=dfcat;290858]"
                  Originally posted by staalmannen View Post
                  I am curious to know... would a DragonFly vkernel be able to run in user land of another OS? It is considered similar to UML but I wonder if it also could be used similarly to coLinux.
                  "

                  The vkernel requires some host-side support - specifically ability to create 'vmspaces' which are separate virtual memory maps,
                  and also a some minor hooks to interface to hardware / host side resources. Doable, but alot of work. Someone interested in knowing
                  this level of detail would be better of giving DF hardware assisted virtualization so you could run DF and virtualize the 'other' os where
                  needed

                  UML iirc also required same.

                  Probably the best bet right now to run dragonfly on another OS is virtualization e.g. via KVM / QEMU / VirtualBox.
                  I am personally, other than on several native dragonfly machines, running df on VirtualBox/Linux, with some devs using KVM.
                  Thanks for the clarifications

                  Personally I just find chroots/jails in directories so much more convenient than typical virtualization and disk images and I think it would be really cool to be able to boot a BSD system directly on top of a Linux kernel (for all that pesky hardware that may not want to work otherwise)

                  Just another question - how does the vkernel compare to NetBSD RUMP? It can be run on different OSes (although I have failed building it on my Linux system) but on the other hand, it does not support running applications but rather provides various kernel features like file systems etc.

                  Comment


                  • #10
                    Originally posted by dfcat View Post
                    Also - performance tests indicate that clang (which FreeBSD will be switching to in 10.x) - is superior to gcc
                    in some performance tests, but slower in others - so in other words, they are extermely competitive:

                    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
                    I someone who regularly benchmarks clang/llvm vs GCC I can say I've not seen any results (atleast not as recent as this year, before that my memory may fail me) where clang/llvm beats GCC where I use -O3, which is the optimization level where the compilers strive to produce the fastest code. And as we can see from the results you linked to, whenever -O3 is used GCC is 'superior' to clang/llvm, and also in most of the cases where no optimization level is set (which really doesn't count though as it is worthless) and the only times clang/llvm beats GCC is when there is no -O optimization level which means GCC defaults to -O0 which is 'no optimization' and aimed for debugging.

                    Typically my tests results in 5-20% better performance with GCC versus clang/llvm, and when I've tried the GCC 4.8 versus LLVM 3.2 snapshots GCC has actually increased the performance gap (that said, snapshots are anything but conclusive). It should be noted that my benchmarks are all on x86_64, I have no idea of how x86 or for example ARM architectures compare.

                    On another note I find Dragonfly most interesting from a technical standpoint, keep up the good work!

                    Comment

                    Working...
                    X