Announcement

Collapse
No announcement yet.

FreeBSD 12.0 vs. DragonFlyBSD 5.4 vs. TrueOS 18.12 vs. Linux On A Tyan EPYC Server

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

  • FreeBSD 12.0 vs. DragonFlyBSD 5.4 vs. TrueOS 18.12 vs. Linux On A Tyan EPYC Server

    Phoronix: FreeBSD 12.0 vs. DragonFlyBSD 5.4 vs. TrueOS 18.12 vs. Linux On A Tyan EPYC Server

    Last month when running FreeBSD 12.0 benchmarks on a 2P EPYC server I wasn't able to run any side-by-side benchmarks with the new DragonFlyBSD 5.4 as this BSD was crashing during the boot process on that board. But fortunately on another AMD EPYC server available, the EPYC 1P TYAN Transport SX TN70A-B8026, DragonFlyBSD 5.4.1 runs fine. So for this first round of BSD benchmarking in 2019 are tests of FreeBSD 11.2, FreeBSD 12.0, DragonFlyBSD 5.4.1, the new TrueOS 18.12, and a few Linux distributions (CentOS 7, Ubuntu 18.04.1 LTS, and Clear Linux) on this EPYC 7601 server in a variety of workloads.

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

  • #2
    I think it would be more informative to test any FreeBSD "current" snapshot with debug options disabled, despite that not being the default. Eventually, the debug options will be disabled when it becomes an officially released version, and all they do is slow down performance, which might explain some of the regressions or lack of significant differences between 11.2 and 12 current.

    Also, I know this is an off-topic request, but can openSUSE Tumbleweed be benchmarked against other rolling releases at some point soon? I'd like to see how it stacks up against Antergos, Clear, Solus, and any other rolling releases since I'm going to be moving over to use it full-time on my desktop and laptop.

    Comment


    • #3
      Originally posted by OpenSourceAnarchist View Post
      I think it would be more informative to test any FreeBSD "current" snapshot with debug options disabled, despite that not being the default. Eventually, the debug options will be disabled when it becomes an officially released version, and all they do is slow down performance, which might explain some of the regressions or lack of significant differences between 11.2 and 12 current.

      Also, I know this is an off-topic request, but can openSUSE Tumbleweed be benchmarked against other rolling releases at some point soon? I'd like to see how it stacks up against Antergos, Clear, Solus, and any other rolling releases since I'm going to be moving over to use it full-time on my desktop and laptop.
      12.0- is RELEASE and not CURRENT. 12.0 doesn't have debug options enabled, only TrueOS based upon 13-CURRENT would have debug options enabled. But AFAIK they are compile-time enabled and can't be disabled simply at run-time, hence why it's tested the way it is.
      Michael Larabel
      http://www.michaellarabel.com/

      Comment


      • #4
        Originally posted by OpenSourceAnarchist View Post
        I think it would be more informative to test any FreeBSD "current" snapshot with debug options disabled, despite that not being the default.
        I doubt Micheal would want to spend extra time on recompiling in order to get rid of debug options in -CURRENT.

        The GCC-based operating systems were the fastest with the C-Ray ray-tracer.


        Typo or imprecise statement, as DragonFlyBSD is also GCC-based and is slowest of the bunch

        Comment


        • #5
          Thanks for including the Himeno benchmark.

          Would love to see Himeno on Intel vs AMD with FreeBSD and Linux.

          Comment


          • #6
            Originally posted by Michael View Post

            12.0- is RELEASE and not CURRENT. 12.0 doesn't have debug options enabled, only TrueOS based upon 13-CURRENT would have debug options enabled. But AFAIK they are compile-time enabled and can't be disabled simply at run-time, hence why it's tested the way it is.
            Sorry about that. My mind reverted back to before the latest release! My bad.

            And I wasn't aware they were compile-time enabled, so that makes sense why they aren't easily disabled. Thanks for the clarification!

            Comment


            • #7
              Originally posted by OpenSourceAnarchist View Post
              And I wasn't aware they were compile-time enabled, so that makes sense why they aren't easily disabled. Thanks for the clarification!
              Yeah, there are bunch of options in kernel config file that have to be disabled, if one wants to disable debugging and then you'd have to recompile kernel.
              Example: https://github.com/freebsd/freebsd/b...4/conf/GENERIC
              Or kernel could be recompiled using a KERNCONF=GENERIC-NODEBUG which would save you from manual editing of GENERIC. Either way works same.
              Code:
              # Debugging support.  Always need this:
              options     KDB            # Enable kernel debugger support.
              options     KDB_TRACE        # Print a stack trace for a panic.
              # For full debugger support use (turn off in stable branch):
              options     BUF_TRACKING        # Track buffer history
              options     DDB            # Support DDB.
              options     FULL_BUF_TRACKING    # Track more buffer history
              options     GDB            # Support remote GDB.
              options     DEADLKRES        # Enable the deadlock resolver
              options     INVARIANTS        # Enable calls of extra sanity checking
              options     INVARIANT_SUPPORT    # Extra sanity checks of internal structures, required by INVARIANTS
              options     WITNESS            # Enable checks to detect deadlocks and cycles
              options     WITNESS_SKIPSPIN    # Don't run witness on spinlocks for speed
              options     MALLOC_DEBUG_MAXZONES=8    # Separate malloc(9) zones
              options     VERBOSE_SYSINIT=0    # Support debug.verbose_sysinit, off by default
              # Warning: KUBSAN can result in a kernel too large for loader to load
              #options     KUBSAN            # Kernel Undefined Behavior Sanitizer
              Last edited by aht0; 01-10-2019, 05:55 PM. Reason: fixed parsing between CODE tags

              Comment


              • #8
                The PHP benchmarks are not representative: CentOS comes with PHP 5.6 and Ubuntu with 7.2. In a couple easy comparisons I found that CentOS with 7.2 runs faster than Ubuntu...

                Comment


                • #9
                  I am a BSD fan, thanks for including so many options in your benchmarks.

                  Comment

                  Working...
                  X