Announcement

Collapse
No announcement yet.

Intel's Clear Linux Outpacing Ubuntu 22.04 LTS, Fedora 36 & Other H1'2022 Distros

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

  • Intel's Clear Linux Outpacing Ubuntu 22.04 LTS, Fedora 36 & Other H1'2022 Distros

    Phoronix: Intel's Clear Linux Outpacing Ubuntu 22.04 LTS, Fedora 36 & Other H1'2022 Distros

    Given the recent releases of Ubuntu 22.04 LTS and Fedora 36 among other recent OS updates, it's time for a fresh look at how various Linux distributions are performing. This Linux benchmarking bout is looking at the Xeon Platinum 8380 2P "Ice Lake" performance across Arch Linux, Debian, openSUSE, CentOS Stream, AlmaLinux, Fedora, Ubuntu, and Intel's Clear Linux.

    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
    I wonder if shedutil is responsible for the bad performance of arch linux.

    Comment


    • #3
      These articles provide a ton of value!

      It is very interesting to see that the new CentOS Stream and AlmaLinux distros having performance in mind as these are the first distros in a long time to go head-to-head with Clear Linux. Bravo!

      Also, on a more personal note, I have been using Fedora as a sort-of upstream version of RedHat EL, trying to be one step ahead of things to come. This approach worked in general and I have been very comfortable on Fedora since, I think, around Fedora 9. Comparing its performance to CentOS Stream it seems that RedHat is serious in incubating new tech in CentOS Stream. I'll need to have a look into that ...

      Comment


      • #4
        The 1001th comparison of distros performance without getting to the root of it and thus making it impossible to understand what could be done for your distro:
        • GCC flags? (I guess the most important)
        • Kernels' CONFIG_HZ/CONFIG_PREEMPT settings?
        • Kernels' debugging options?
        • Default schedulers and their options?
        • Something else?
        What about documenting all of that for the betterment of Linux?

        What about running distro_X with the kernel from distro_Y? What if that's enough to make it equally fast?

        Comment


        • #5
          Originally posted by birdie View Post
          The 1001th comparison of distros performance without getting to the root of it and thus making it impossible to understand what could be done for your distro:
          It's simple: Different software versions (newer is mostly better), different compiler flags (less generic is better) and different CPU scaling governors (performance is faster than balanced or powersave).
          Last edited by -MacNuke-; 19 May 2022, 08:57 AM.

          Comment


          • #6
            Originally posted by -MacNuke- View Post

            It's simple: Different software versions (newer is mostly better), different compiler flags (less generic is better) and different CPU scaling governors (performance is faster than balanced or powersave).
            Why you quoted my own suspicions is beyond me. The question is: have you actually tested anything? What makes you so bloody confident, "it's simple"?

            Comment


            • #7
              Ubuntu in the meanwhile: let's add some more Snaps.

              Comment


              • #8
                Originally posted by birdie View Post
                The 1001th comparison of distros performance without getting to the root of it and thus making it impossible to understand what could be done for your distro.
                I agree. You're asking the logical question based on the data presented.

                I noted that without these 1001 articles the, in some cases significant, performance differences would not be documented.

                Comment


                • #9
                  Originally posted by birdie View Post
                  The 1001th comparison of distros performance without getting to the root of it and thus making it impossible to understand what could be done for your distro:
                  • GCC flags? (I guess the most important)
                  • Kernels' CONFIG_HZ/CONFIG_PREEMPT settings?
                  • Kernels' debugging options?
                  • Default schedulers and their options?
                  • Something else?
                  What about documenting all of that for the betterment of Linux?

                  What about running distro_X with the kernel from distro_Y? What if that's enough to make it equally fast?
                  As Michael has written a few times now: The intent is to show distro performance out of the box. No one is stopping you from doing the analysis you requested yourself.

                  Comment


                  • #10
                    Arch Linux is one of the slowest distro, when a decade ago it used to be one of the fastest. They need a x86-64v3 port as soon as possible.

                    Comment

                    Working...
                    X