Announcement

Collapse
No announcement yet.

The Performance Impact Of GCC CPU Tuning On The Linux Kernel's Performance

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

  • #31
    Originally posted by HyperDrive View Post
    You're comparing optimisation levels on machines which are deeply OoO and have huge instruction windows and/or reorder buffers. The results are as expected, obviously. Now, I'd love to see the same comparison on an old Atom (Diamondville, Pineview or Cedarview, all Bonnell microarchitecture) system and on the Raspberry Pi 1/Zero.
    Wouldn't it be even less of an effect on an older processor where there are fewer machine-specific optimizations being held back by the compiler?

    Comment


    • #32
      Originally posted by sarfarazahmad View Post
      Now I am curious. Where does ClearLinux stand on this ?
      It would be interesting to see arch linux as well

      Comment


      • #33
        Originally posted by dungeon View Post

        I tested this some years ago on AMD Kabini so Jaguar arch and got same results like Michael is getting, somewhere goes up a bit and somewhere also flop

        Not needed really
        Jaguar is also speculative OoO. My point is that the impact of different optimisation levels is much greater on microarchitectures which rely on the compiler for scheduling optimal code. x86(-64) Bonnell, ARM up to v6 and some v7 (Cortex-A7 and A8, for example) and most of MIPS (except for 74Kc/1074Kc, that I remember) are in-order and statically scheduled.

        Comment


        • #34
          Originally posted by ckonte View Post
          moltonel No downside, unless you use a binary based distro like pretty much everyone.
          It clearly makes sense only for gentoo users, that's why it should stay in gentoo imho.
          Tell me, what's the downside for people using a precompiled kernel ? There's no upside sure, but no downside either.

          Also, don't conflate "Gentoo users" with "people compiling their kernel", as the groups are completely orthogonal. There are Gentoo users with autogenerated kernels, and there are (plenty of) non-Gentoo users compiling their own kernel.

          Lastly, if you're using a kernel precompiled for a raspberry py for example, whoever configures the compilation could benefit from the patch.

          Comment


          • #35
            Originally posted by re:fi.64 View Post

            Wouldn't it be even less of an effect on an older processor where there are fewer machine-specific optimizations being held back by the compiler?
            No, it's not a matter of age.

            Comment


            • #36
              Originally posted by Veto View Post
              But, what is not measured, is the *feeling* of running a bleeding edge kernel you have tailored, optimized and built specifically for your machine. With all the sense of accomplishment it surely *feels* faster.

              Unfortunately these benchmarks deprive people of getting that feeling...

              (Tried it a couple of times ages ago, but although a fun exercise I realized the futility of it.)
              I'm a happy Gentoo user, but I have no illusion that it results in a noticeably faster desktop (especially once you account for the time spent compiling). I suppose not needing an initramfs speeds the boot up, but I don't boot that often.

              I know Phoronix is all about benchmarks, but there are other things to consider. The gains come mainly from what you compile rather than what compile-time optimizations you apply. Improve security by reducing the attack vector. Simplify usage (and yes, speed things up) by removing stuff you don't need. Mix mature and bleeding-edge software easily and cleanly. Have more alternatives even for core packages. Write your own package much more easily. All these nice attributes derive from the principle of compiling your own, and are hard or impossible to achieve on a binary distro.

              If you think it's about the speed, you don't know what you're missing.

              Comment


              • #37
                debianxfce must be raging...

                Comment


                • #38
                  Originally posted by moltonel View Post
                  If you think it's about the speed, you don't know what you're missing.
                  That was exactly my argument Although tempted to try out Gentoo some time and relive the old days of Slackware, kernel compiles and endless tinkering, these days I just use a distro that makes it possible to spend my time on something more productive.

                  But, please! Have good fun with whatever makes you tick
                  Cheers

                  Comment


                  • #39
                    Originally posted by moltonel View Post

                    Tell me, what's the downside for people using a precompiled kernel ? There's no upside sure, but no downside either.

                    Also, don't conflate "Gentoo users" with "people compiling their kernel", as the groups are completely orthogonal. There are Gentoo users with autogenerated kernels, and there are (plenty of) non-Gentoo users compiling their own kernel.

                    Lastly, if you're using a kernel precompiled for a raspberry py for example, whoever configures the compilation could benefit from the patch.
                    The downside is that all the binary based distros have to set the flag back to a generic value, which leads me to the following question: Why they should put a default value that doesn't make sense for the vast majority of the users?
                    Moreover I completely agree with Ingo Molnar's comment. It's not acceptable from a maintainability point of view to have a different compilation output for every single micro architecture out there. It could be that a patch causes a regression on a AMD cpu, but you don't see it because you have an Intel cpu and for some reason the optimization flag hides the issue. Just one more variable that makes life harder for the kernel developers. Also, do you think it's feasible to test every single possible output of this patch?
                    You know, most of the people working on a pc want stability, not optimizations that might work.
                    You should trust the kernel maintainers, they know their job better than we do.

                    Comment


                    • #40
                      Performance wont change much, but there is something that annoys me alot when it comes to ARM. Their 32 "performance" Cortex-A Architecture has an optional integer division, which is outrageous for so many reasons (last but not least: their low power Cortex-M Architecture has this guaranteed).
                      You dont have a config to compile the kernel for the vast majority of Cortex-A cpus with idiv, leaving a function call to a software fallback in place. The kernel however has an option to dynamically patch out the function calls and put an idiv instruction in place (still leaving the overhead that's necessary to setup the function call and return).
                      So much trouble for patching the live kernel, and no care for just adding a config for ignoring some fringe CPUs....

                      Comment

                      Working...
                      X