Announcement

Collapse
No announcement yet.

Initial Benchmarks Of Endeavour OS - The New Linux Distro Based On Arch

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

  • #21
    Maybe CONFIG_NO_HZ_FULL is used for out of the box support of audio applications. Running Jack applications on arch is pretty straight forward and they work nicely, which I think is due to the usage of this kernel flag.

    Comment


    • #22
      Originally posted by TheOne View Post
      Maybe CONFIG_NO_HZ_FULL is used for out of the box support of audio applications. Running Jack applications on arch is pretty straight forward and they work nicely, which I think is due to the usage of this kernel flag.
      You shouldn't need CONFIG_NO_HZ_FULL to play audio. Is there a distro that has issues with that, on Jack or otherwise?

      From the docs, it's mostly intended for HPC systems (big servers) and hard(er) real-time applications.

      Comment


      • #23
        Originally posted by ChadD View Post
        The main advantage in terms of performance for arch isn't its "out of the box" settings. The advantage is being more customizable then most distros. I notice based on this testing it is also noticeably faster in regards to context switching. I am sure that is part of why it feels so subjectively fast to most people. It's a great distro for real world use where your opening closing and tabbing around.

        The combo of running exactly what you want how you want it and blazing fast context switching makes for a very pleasant desktop experience.

        For pure speed of course clear is still the king of benchmarks and a terrible everyday distro. Opensuse might just be one of the best performance distros around right now imo but only if your willing to tinker with their default. If you just install and click next next next next and go with btrfs and its other defaults it's just average.
        To be fair, there's no 'out of the box configuration' for Arch, at least not on user level (aside from package compilation that is actually important for performance). So yeah, aside from maybe few specific scenarios (such as x265 on openSUSE example) , user configuration wouldn't really play any/big role in it.

        The whole idea of Arch is to make simple to use operating system, with easilly solvable dependencies via simple package manager, with only packages that are needed for particular use-case scenario of the end user, and with 'rolling' upgrade model to simplify the process. It is ofc. assumed that end user is knowledgable enough to know what he needs, and specific configurations he may need to do for specific use-case, that ofc. isn't always the case, in many cases end user can install 'package group' and does not have to worry about what specific packages are needed, for example 'gnome' group, or 'gnome-extra' group, and in such scenario user doesn'\t really have to know much about it at all, all he needs to know is that it is required from him to configure 'display manager' by simply enabling service for standard GDM for GNOME for example, or replacing it by any other display manager such as LightDM and so on.
        So in that sense, 'KISS principle' suggests that there's really no point in having Arch based distribution, because it goes against principle itself = direct contradiction.

        It does however make life easier for testing purposes to have some base distribution to save time, and lack of well maintained proper script that would do such thing furthers that point. And there are many advantages and disadvantages for such system, one disadvantage would be that if you don't want to be annoyed by automatic checks for updates and constant updating, you may have to use manual schedule process for that task. The big and obvious advantage is that you can run it for years without need for re-installing (or potentially problematic upgrade process) in order to get newer versions of packages.

        Comment


        • #24
          Thank you Michael for the last bench test summary table. It MIGHT quieten the apologies, excuses & debates from the fanboys. For those of us who read these Phoronix reports constantly, there are few differences from the previous results. Clear Linux is as usual the leader, regardless of the CPU being tested. All the other results are well in line with the usual Phoronix results.
          The disappointed apologists need to be more factual on their apologies however. For example the Debian-based operating systems can use any of the Linux kernels from the official Ubuntu web site. If Ubuntu's official "lowlatency" kernel was chosen, would the results change?
          Many disappointed comments explain that "IF ONLY" certain tweaks & optimizations were used, the results would be different; which is very true.
          Part of the problem could be from several sources, which these benchmarks do not explain.
          (1) When the distributions are tested, are the basic defaults left the same? Some systems default with BTRFS, which happens to be slow with benchtests.
          (2) During & after the first installation, some (all?) operating systems "update" their components to different from the first ISO of the operating system. Often this means a change in the Linux kernel. How many of these updates are allowed before testing. When tested, the internal components of the operating system change. Perhaps stating which Linux kernel is used might allow us to know better how deviated it was from the first ISO download.
          (3) Other hardware drivers may also change. A common example is that some hardware (e.g. Nvidia) MIGHT work better than the default open source drivers of the first, unimproved ISO.
          (4) It might be explained also that there is more to an operating system than benchtests. Improved stability, reliability & recover-ability might be preferred over race-track performance. So the slower operating systems (openSUSE, RHEL, etc) might be preferred, when these other user concerns are important. This MIGHT comfort the "losers" in any race track performance.
          (5) Many comments so far are confused about which operating systems were tested in this report. In particular, the Arch users ignore the fact that Endeavour OS is not at all "Arch". Perhaps if Arch is ever tested, it could be compared with Manjaro, Netrunner & other Arch-based operating systems, with the usual "official running" updates.
          Last edited by gregzeng; 26 July 2019, 05:56 AM. Reason: spelling corrected.

          Comment


          • #25
            Originally posted by gregzeng View Post
            Part of the problem could be from several sources, which these benchmarks do not explain.
            Regarding point #1, Michael usually runs benchmarks with system defaults. This has been a perennial forum complaint in the past, when common tweaks were more important for (usually graphics) performance, but the consistency is understandable.

            Regarding points #2-3, and verifying #1 for filesystems, the first table on Page 1 of the article shows the system specifications, including kernel and display-driver versions, which PTS records in each OS right before running the benchmarks. Any such updates would appear there. (Although I doubt Michael would manually run updates for stable releases.)

            Comment


            • #26
              Originally posted by GrayShade View Post
              You shouldn't need CONFIG_NO_HZ_FULL to play audio. From the docs, it's mostly intended for HPC systems (big servers) and hard(er) real-time applications.
              This is interesting:



              TL;DR: "I set CONFIG_NO_HZ_IDLE because Clear Linux does. I don't know what I'm doing and won't change my opinion."

              Comment

              Working...
              X