Announcement

Collapse
No announcement yet.

The Fastest Linux Distribution For Ryzen: A 10-Way Linux OS Comparison On Ryzen 7 & Threadripper

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

  • #21
    Surprised that no has mentioned that Clear Linux ships an updated glibc (libm in particular) -- it's been reported on phoronix earlier..

    Comment


    • #22
      Originally posted by thebear View Post
      Surprised that no has mentioned that Clear Linux ships an updated glibc (libm in particular) -- it's been reported on phoronix earlier..
      we certainly spent a lot of time on optimizing glibc upstream and then including that into Clear Linux in parallel
      (some people call those "out of tree patches" of course)

      the glibc folks are nice enough to put that into their NEWS announcements: https://sourceware.org/git/?p=glibc....a1;hb=HEAD#l22

      Comment


      • #23
        Originally posted by thebear View Post
        Surprised that no has mentioned that Clear Linux ships an updated glibc (libm in particular) -- it's been reported on phoronix earlier..
        Glibc trying to force push various recent SSE instructions by default, which breaks various older builded apps for people xyz inside distro but also much elsewhere... as always we in Debian disable that. Well if you are interested, just install it from experimental and look at improvments and breakages, it will probably be better by the time

        On Linux i only recommend Debian or Fedora as sane optimal most of the time, others are free to go crazy up and down anytime and i don't care
        Last edited by dungeon; 25 January 2018, 06:28 PM.

        Comment


        • #24
          Originally posted by dungeon View Post

          Glibc trying to force push various recent SSE instructions by default, which breaks various older builded apps for people xyz inside distro but also much elsewhere... as always we in Debian disable that. Well, just install it from experimental and look at improvments and breakages

          On Linux i only recommend Debian or Fedora as sane optimal most of the time, others are free to go crazy up and down anytime and i don't care
          all of these things are runtime detection for support... if you dont have the instruction you get the old version of the function.
          And as always glibc testsuite tests for numerical accuracy for all of this.

          Comment


          • #25
            AFAIK recently these breaks a lot of games on Steam, of course you might not care about all these but some people do and nowdays these also coming to file bugs

            Comment


            • #26
              Originally posted by dungeon View Post
              AFAIK recently these breaks a lot of games on Steam, of course you might not care about all these but some people do
              the libm optimizations do not break steam games.

              (something in glibc interacted with steam. not libm)

              Comment


              • #27
                Originally posted by arjan_intel View Post

                the libm optimizations do not break steam games.

                (something in glibc interacted with steam. not libm)
                OKet, but that is like saying "It is not a kernel but drivers" Our bugzilla are same for both as these are in same package.

                But thanks for cool improvments i spotted some improvments with it on Debian too... or maybe i see perf improvemnts from others there, unsure in this whatever, for the rest of the world that will be in Debian 10 next year

                It is early to claim anything, since all CPU vulnerabilities mitigations, firmwares... aren't in place yet... on one place improvment on other degradations and it might be in the end quite the same
                Last edited by dungeon; 25 January 2018, 07:43 PM.

                Comment


                • #28
                  Originally posted by sa666666 View Post
                  Yep, that's why I personally would like to see 32-bit distro's disappear. Then we can assume that the lowest common denominator isn't a CPU from 20 years ago, and actually make use of compiler flags for CPUs made in this decade.
                  Nice trolling pal. 32-bit distros don't have any effect on x86-64 distros. What's true is that you could optimize the 32 bit versions a lot more if you assumed all the instruction set updates like SSE2. Coffee lake / Zen optimized x86 runs much faster than code that targets i586 or i686 due to all the advancements between 1995 and 2018, even for x86 code.

                  Comment


                  • #29
                    Originally posted by dungeon View Post
                    AFAIK recently these breaks a lot of games on Steam, of course you might not care about all these but some people do and nowdays these also coming to file bugs
                    Actually that was a library path issue where `x86_64` path was ignored, and the only other "big break" in glibc for Steam in the last few years was a GCC bug that generated invalid i686 glibc and crashed certain games (Such as Borderlands). Certainly nothing to do with `libm` optimisations.

                    Comment


                    • #30
                      Originally posted by ikey_solus View Post

                      Actually that was a library path issue where `x86_64` path was ignored, and the only other "big break" in glibc for Steam in the last few years was a GCC bug that generated invalid i686 glibc and crashed certain games (Such as Borderlands). Certainly nothing to do with `libm` optimisations.
                      I believe he was talking about this bug that just got fixed (/reverted):
                      https://sourceware.org/bugzilla/show_bug.cgi?id=22743

                      Comment

                      Working...
                      X