Announcement

Collapse
No announcement yet.

Linux Still Yields Better Multi-Threaded Performance On AMD Threadripper Against Windows 10 May 2019 Update

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

  • #11
    Originally posted by M@GOid View Post
    And while the Microsoftee regurgitates all that corporation talk crap, you can see Lisa Su thinking "yeah yeah, but can you fix your crap Windows scheduler so Threadripper doesn't look so bad on Windows?"
    During the Computex presentation, it was most importantly about Epyc and Microsoft Azure. The majority of Azure runs on Linux nowadays.

    Comment


    • #12
      Originally posted by starshipeleven View Post

      .yes.
      But.. how? why?

      Comment


      • #13
        Originally posted by milkylainen View Post
        Darktable broken on Linux? There is no way a CPU-bound application has 20x speedup on another platform unless something is seriously fubared.
        Or a FS flush or sync is missing on the other platform. We see a similar thing with sqlite on macOS where they don't do fsync correctly.

        Comment


        • #14
          Originally posted by JeansenVaars View Post

          But.. how? why?
          - Microsoft worked with Canonical to bring WSL
          - Ubuntu suddenly became slower IN SOME TASKS after WSL was announced (this is proved by the multi-distro plus WSL benchmarks... you can see Ubuntu SOMETIMES being slower than its WSL version and other Linux distros)
          Last edited by tildearrow; 28 May 2019, 02:56 PM.

          Comment


          • #15
            I don't think this is specific to Threadripper. I didn't do strict consistent tests or do much out of the way from defaults (at the very least, Windows was in Ultimate Performance power mode), but I ran Geekbench some months back with 2 Opteron 4386 CPUs (Piledriver):

            Windows: https://browser.geekbench.com/v4/cpu/11817036
            Linux: https://browser.geekbench.com/v4/cpu/11676197

            I've also ran it at random times after that date (can see them all here), but the general consistency is that the multithreaded test scores a bit higher on Linux than it does Windows.

            Comment


            • #16
              Originally posted by torsionbar28 View Post
              I imagine in both cases, Michael used the official binaries as published by the author/distro. The compiler would therefore be the "default" one, and that's all that matters. An end user will not be compiling any code, especially on Windows. If Michael did custom builds of these apps, the benchmarks would be meaningless, since literally nobody else would be using his binaries. It's not an "os-to-os" comparison, it's an OS+app vs OS+app comparison i.e. "real world" scenario.
              You are probably right. It would be interesting to run e.g. the Windows version of Darktable or FFmpeg under Wine in Ubuntu and see what result we would get.

              Comment


              • #17
                Originally posted by tildearrow View Post

                - Microsoft worked with Canonical to bring WSL
                - Ubuntu suddenly became slower after WSL was announced (this is proved by the multi-distro plus WSL benchmarks... you can see Ubuntu being slower than its WSL version and other Linux distros)
                Not convinced, not without proof. Doesn't make sense into what canonical gains out of this. Sounds like win-hate to me.

                Comment


                • #18
                  Originally posted by tildearrow View Post

                  - Microsoft worked with Canonical to bring WSL
                  - Ubuntu suddenly became slower after WSL was announced (this is proved by the multi-distro plus WSL benchmarks... you can see Ubuntu being slower than its WSL version and other Linux distros)
                  Have you used WSL? It might be fast in CPU-bound tasks but if you touch the disk at all you go back a decade in performance.

                  Comment


                  • #19
                    The sad thing is that the benchmark results do not matter one bit; the reality is that Windows is a much more usable OS than Linux and this is coming from a guy that can't stand Win 10 and has been using Linux since before Suse became Open Suse and before Fedora was even conceived, back then I was running Red Hat with the Ximian Gnome desktop and I loved it. Today I run Manjaro at home exclusively but the sad truth is that the Os is not what matters most, it's the apps and Windows beats Linux hands down in that department, as does OSX.

                    The reality is that if I wanted to build a high end video or audio editing/production system or a 3d rendering system, even though I can get a lot done with Linux, I would still need a Windows system at some point in the production pipeline, but if I have a Windows system I can do just fine without a Linux system.

                    Same thing with OSX, as much as I can't stand Apple or their overpriced hardware, if I buy a decked out Mac, I can install all the software I will need and just use that one system for everything, with Linux I am limited to open source software with some limited proprietary software.

                    Doesn't do you any good to have a muscle car if you don't have a license or insurance and can't drive it on most roads.

                    Comment


                    • #20
                      Originally posted by randomizer View Post

                      Have you used WSL? It might be fast in CPU-bound tasks but if you touch the disk at all you go back a decade in performance.
                      It's because Windows doesn't implement a real IO scheduler, instead it uses a system of "time slices", eg it issues IO in slices of time where between each slice is a context switch and if the IO operation isn't ready in time for the time slice then it's filled with a serial string of context switches until the next time slice. Time slices can't match up perfectly with every IO operation and that forces constant pipeline flushes and refills in windows. It's just how it is, at least until MS implements a proper IO scheduler. Windows will context switch on IO for as long as MS refuses to write a proper IO scheduler.
                      Last edited by duby229; 28 May 2019, 09:18 AM.

                      Comment

                      Working...
                      X