Announcement

Collapse
No announcement yet.

DragonFlyBSD's Kernel Optimizations Are Paying Off - 3 BSDs & 5 Linux OS Benchmarks On Threadripper

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

  • DragonFlyBSD's Kernel Optimizations Are Paying Off - 3 BSDs & 5 Linux OS Benchmarks On Threadripper

    Phoronix: DragonFlyBSD's Kernel Optimizations Are Paying Off - 3 BSDs & 5 Linux OS Benchmarks On Threadripper

    DragonFlyBSD lead developer Matthew Dillon has been working on a big VM rework in the name of performance and other kernel improvements recently. Here is a look at how those DragonFlyBSD 5.5-DEVELOPMENT improvements are paying off compared to DragonFlyBSD 5.4 as well as FreeBSD 12 and five Linux distribution releases. With Dillon using an AMD Ryzen Threadripper system, we used that too for this round of BSD vs. Linux performance benchmarks.

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

  • #2
    For the OpenMP workloads, have you tried setting OMP_PROC_BIND to "true"? I have found that this makes a big difference to OpenMP's performance on Threadripper. Unlike the 2950X, I believe the 2990WX can only be operated in NUMA mode, which is what hurts OpenMP's performance.

    Comment


    • #3
      That's a lot of improvements. Congrats to the DragonflyBSD devs!

      Comment


      • #4
        Originally posted by profoundWHALE View Post
        That's a lot of improvements. Congrats to the DragonflyBSD devs!
        Yeah, it went from being the last in most benchmarks to... being the last in most benchmarks.

        Comment


        • #5
          I guess I'm strange, but from my point of view reading through the benchmark scores the comment came to mind, not that Dragonfly BSD had a big improvement in upcoming 5.5, but that ye old basic (boring?) FreeBSD 12 performance "didn't suck" any more compared to Linux for many of those tests. Solid performance numbers there.

          Now if only FreeBSD would get on the ball with getting serious about security and having it not take a back seat to 20 year old compatibility knobs... (which is why HardenedBSD exists).

          Comment


          • #6
            Some of these tests results are just impossible to believe outside of a major configuration misshap, that x265 which is extremely cpu bound and heavily assembly optimized would be ~30% faster on FreeBSD compared to Ubuntu 19.04 just makes zero sense.

            Comment


            • #7
              Wonder what particular variant of FreeBSD12 was used in test.

              In mid-April, jump from Clang 6.0 to Clang 8.0 happened. 12-RELEASE came out using Clang 6 for system compiler but 12-STABLE has been using Clang 8.0 now. I imagine both perform quite differently.

              Comment


              • #8
                Originally posted by stormcrow View Post
                old basic (boring?) FreeBSD 12 performance "didn't suck" any more compared to Linux for many of those tests. Solid performance numbers there.
                It seems they did a good thing by moving to clang. It may also depend on tests selection. What's funny it sucks in bsd licensed postgreSQL.

                Comment


                • #9
                  Originally posted by stormcrow View Post
                  I guess I'm strange, but from my point of view reading through the benchmark scores the comment came to mind, not that Dragonfly BSD had a big improvement in upcoming 5.5, but that ye old basic (boring?) FreeBSD 12 performance "didn't suck" any more compared to Linux for many of those tests. Solid performance numbers there.

                  Now if only FreeBSD would get on the ball with getting serious about security and having it not take a back seat to 20 year old compatibility knobs... (which is why HardenedBSD exists).
                  You seem to totally miss the point of hardenedbsd. It's a fork so they can 'be innovative' (their words) with security. Freebsd is very conservative so doing this in freebsd's kernel is a no-go. Once valid code is proven it likely makes it into freebsd in a future release.

                  Comment


                  • #10
                    Originally posted by Bsdisbetter View Post

                    You seem to totally miss the point of hardenedbsd. It's a fork so they can 'be innovative' (their words) with security. Freebsd is very conservative so doing this in freebsd's kernel is a no-go. Once valid code is proven it likely makes it into freebsd in a future release.

                    No I haven't missed the point of HardenedBSD at all. In fact I purposely pointed out why it exists, which you apparently ignored. I simply disagree with FreeBSD's problematic stance on conservative compatibility at the expense of the security of the entire platform.

                    Comment

                    Working...
                    X