Announcement

Collapse
No announcement yet.

The Ryzen 7 1800X Linux Performance Evolution Since The AMD Zen Launch

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

  • The Ryzen 7 1800X Linux Performance Evolution Since The AMD Zen Launch

    Phoronix: The Ryzen 7 1800X Linux Performance Evolution Since The AMD Zen Launch

    With it quickly approaching two years since the launch of the original AMD Ryzen processors and complementing our other end-of-2018 Linux performance benchmarks, in this article are some fresh benchmarks seeing how the Linux performance at the start of 2017 on the Ryzen 7 1800X compares to the latest Linux performance at the start of 2019.

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

  • #2
    Nice improvements. In the meantime, windows CPU scheduler is still so bad, that CPU heavy programs have to implement their own scheduler to keep performance on par with Linux.

    Prime example: RPCS3.

    Comment


    • #3
      Originally posted by eydee View Post
      Nice improvements. In the meantime, windows CPU scheduler is still so bad, that CPU heavy programs have to implement their own scheduler to keep performance on par with Linux.

      Prime example: RPCS3.
      The Windows CPU scheduler has some known bugs, some of it surrounding how NUMA is presented by high core Xeons which is causing issues in other NUMA implementations. (like Threadripper & Epyc) The bugs are known and there are tools recently released which are supposed to help Windows schedule threads better until they can rewrite the kernel to get past the NUMA bug.

      Apparently Microsoft did a quick and dirty patch for these high core Xeons awhile back and they are paying for it.

      Comment


      • #4
        Originally posted by edwaleni View Post

        The Windows CPU scheduler has some known bugs, some of it surrounding how NUMA is presented by high core Xeons which is causing issues in other NUMA implementations. (like Threadripper & Epyc) The bugs are known and there are tools recently released which are supposed to help Windows schedule threads better until they can rewrite the kernel to get past the NUMA bug.

        Apparently Microsoft did a quick and dirty patch for these high core Xeons awhile back and they are paying for it.
        Bing "level1techs coreprio". You are welcome.

        Comment


        • #5
          Originally posted by enihcam View Post

          Bing "level1techs coreprio". You are welcome.
          Yes, I am aware of the tool. I brought it to Michael's attention this morning and he is going to give it a run with PTS since he has Threadrippers in his inventory.

          I didn't want to steal his test thunder.

          Comment


          • #6
            Originally posted by edwaleni View Post

            Apparently Microsoft did a quick and dirty patch for these high core Xeons awhile back and they are paying for it.
            When doesn't Microsoft do things quick and dirty?

            (Edit: I know it's popular for free software enthusiasts to knock Microsoft. But for example one of my brothers is a Microsoft fanatic. And Windows Update just broke his Windows 10 install in December, and he had to do a clean reinstall.)
            Last edited by Michael_S; 01-04-2019, 12:15 PM.

            Comment


            • #7
              Originally posted by edwaleni View Post

              Apparently Microsoft did a quick and dirty patch for these high core Xeons awhile back and they are paying for it.

              Now Microsoft does not do things Quick and Dirty, yet

              "86-DOS - often referred to as QDOS, or Quick and Dirty (written) Operating System -
              https://searchwindowsserver.techtarg...on/QDOS-86-DOS

              But Microsoft removed Quick from that name
              https://www.levenez.com/windows/

              https://www.levenez.com/windows/windows_a4.pdf


              into MS-DOS ...

              Comment


              • #8
                Originally posted by Peter Fodrek View Post


                Now Microsoft does not do things Quick and Dirty, yet

                "86-DOS - often referred to as QDOS, or Quick and Dirty (written) Operating System -
                https://searchwindowsserver.techtarg...on/QDOS-86-DOS

                But Microsoft removed Quick from that name
                https://www.levenez.com/windows/

                https://www.levenez.com/windows/windows_a4.pdf


                into MS-DOS ...
                From Microsoft Dirty Operating System

                to

                We'll Install Newer Debian Or Windows Seven

                Comment


                • #9
                  Its not 100% related to this , but video below explains why linux is faster in certain cases and why scheduler issue in windows kernel is important:
                  https://www.youtube.com/watch?v=M2LOMTpCtLA

                  Comment


                  • #10
                    Originally posted by Peter Fodrek View Post


                    Now Microsoft does not do things Quick and Dirty, yet

                    "86-DOS - often referred to as QDOS, or Quick and Dirty (written) Operating System -
                    https://searchwindowsserver.techtarg...on/QDOS-86-DOS

                    But Microsoft removed Quick from that name
                    https://www.levenez.com/windows/

                    https://www.levenez.com/windows/windows_a4.pdf


                    into MS-DOS ...
                    Yes, Microsoft's historical behavior is well documented. I was in the courtroom for the Seattle Computing Products lawsuit against Bill Gates and Microsoft back in 1988-89 on the claim of fraud around licensing DOS.

                    As for the quick and dirty here, I think the issue is MSFT didn't put a great deal of thought of how they were going to handle NUMA long term. Most of the original work was done in concert with Sequent and the original NT kernel but it didn't work when the core counts exceeded 64 on later Xeon's due to some architectural decisions Intel made. When they made a change in the Server 2008 R2 kernel, some thought it was a kludge to get past the issue and wasn't really addressed properly (as opposed to Linux, which did).

                    So now here we are with a more advanced implementation of NUMA (some say exotic) and that "shortcut" made many years ago is an issue.

                    Comment

                    Working...
                    X