Announcement

Collapse
No announcement yet.

Running FreeBSD 12, TrueOS On AMD EPYC

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

  • Running FreeBSD 12, TrueOS On AMD EPYC

    Phoronix: Running FreeBSD 12, TrueOS On AMD EPYC

    Back in October I did some basic tests of the BSDs on AMD EPYC while now with having more of our extensive Linux testing of AMD EPYC complete, I went back and did a few fresh tests of the BSDs with an AMD EPYC 7601 processor housed within the Tyan Transport SX TN70A-B8026.

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

  • #2
    One thing to note when testing FreeBSD -CURRENT snapshots is that they are compiled with all kinds of debugging stuff enabled, which will slow things down during normal uses. This is by design, as -CURRENT is primarily meant for development, debugging, and bug squashing. Just something to keep in mind when running benchmarks against it.

    If you want to get a better representation of how it will work once released, you need to compile the OS from source and disable all the debugging in /etc/make.conf and (sometimes) in /etc/src.conf.

    I don't know how TruOS does things in their -UNSTABLE branch, if they have the debugging stuff enabled or not. The last time I tried PCBSD/TruOS was in the 9.x days.

    Comment


    • #3
      I want to ask the author to kindle write an article (or point me to one) that describes the optimization changes/additions enabled/added to Clear linux compilation, and if they can be reproduced by recompiling packages in other distributions. Ty in advance!

      Comment


      • #4
        Originally posted by deant View Post
        I want to ask the author to kindle write an article (or point me to one) that describes the optimization changes/additions enabled/added to Clear linux compilation, and if they can be reproduced by recompiling packages in other distributions. Ty in advance!
        That isn't something trivial at all. They use an assortment of approaches from adding extra patches / backporting patches, tuned CFLAGS/CXXFLAGS, function multi-versioning, FDO, changing some kernel tunables, and whatever else. They just aren't setting a few switches or so and calling it a day.

        arjan_intel or so would be able to comment if there is any ClearLinux.org webpage with a list of all their approaches for tuning, but I don't think so. They've done a few presentations at conferences about some of their work, but again just isn't something to easily carry out on another distribution.
        Michael Larabel
        http://www.michaellarabel.com/

        Comment


        • #5
          Clear Linux is an Intel project. They do many different things to make the distribution as fast as possible on Intel CPUs and GPUs. Intel would be the ones to know.

          I don't know if anyone outside of Intel has analysed/documented much of it.

          For a start, you could compile binaries for newer CPUs. Even if not for your specific cpu (`-march=native`) like you would in Gentoo, at least for a more recent family (like `-march=haswell`). I presume this would be one of the many things that Clear Linux does -- providing packages compiled for newer generations of CPUs. Other distros like Ubuntu tend to compile things as generic as possible to support old AMD and Intel CPUs as well (such as the Athlon64 and Core2), which restricts the instruction set extensions and optimisations that the compiler can do. On distros like Ubuntu, your CPU is only executing modern instructions like AVX2 for programs that do runtime cpu detection and have manually optimised assembly modules for different instruction sets (ffmpeg is an example of this, so that your multimedia codecs can always be as fast as possible).

          I don't know what the other optimisations might be. I remember benchmarks showing that even Intel GPU OpenGL performance is better on Clear Linux than other distros. I wonder how they achieve that.

          Comment


          • #6
            Michael

            typo:

            Those initial EPYC BSD tests included FreeBSD 11.1, TrueOS, and FreeBSD 11.1

            Shouldn't it be 12 Current?

            Comment


            • #7
              Interesting that the BSD NVMe driver didn't work. NVMe is supposed to be a hardware standard like AHCI, so the same driver should work for any hardware.

              Comment


              • #8
                openSUSE Tumbleweed 20171204 with default...BTRFS?!

                Disk Details
                - Ubuntu 18.04 LTS 20171205: NONE / data=ordered,errors=remount-ro,relatime,rw
                - openSUSE Tumbleweed 20171204: NONE / relatime,rw,space_cache,ssd,subvol=/@/.snapshots/1/snapshot,subvolid=259
                - Clear Linux 19460: NONE / data=ordered,relatime,rw,stripe=256
                Processor Details
                - Ubuntu 18.04 LTS 20171205: Scaling Governor: acpi-cpufreq ondemand
                - openSUSE Tumbleweed 20171204: Scaling Governor: acpi-cpufreq ondemand
                - Clear Linux 19460: Scaling Governor: acpi-cpufreq performance
                Last edited by nuetzel; 12-06-2017, 08:00 PM. Reason: Extended. - See the CPU governors.

                Comment


                • #9
                  I'd be interested to see if you could do an OpenBSD 6.2 (maybe even a 6.1 comparison) test.

                  Comment


                  • #10
                    O
                    Originally posted by deant View Post
                    I want to ask the author to kindle write an article (or point me to one) that describes the optimization changes/additions enabled/added to Clear linux compilation, and if they can be reproduced by recompiling packages in other distributions. Ty in advance!
                    Of course they can be reproduced. Why do you think Solus has so many Intel optimizations?

                    Comment

                    Working...
                    X