Announcement

Collapse
No announcement yet.

A Quick Look At The Windows Server vs. Linux Performance On The Threadripper 2990WX

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

  • #11
    What a hell joke is this Windows results. A shame!

    Comment


    • #12
      So, if your you have high loading times and your internet sucks overall you know who to blame (and FreeBSD performs similar to Windows!). Of course I'm assuming there's some sanity among people and they didn't choose crap like macOS as a server.

      Comment


      • #13
        Originally posted by Floturcocantsee View Post
        This is embarrassing for Microsoft I can't believe even their "server" line of operating system has NUMA so poorly implemented it would be a bit more acceptable if people weren't spending arm and leg for licenses for this product.
        Windows Server uses the same scheduler as the desktop version.

        Comment


        • #14
          Thanks for including the Go benchmarks, Michael!

          Interesting to see how much fluctuation there are between performance in Window's versions, looks like Linux is very well tuned as it delivers performance in a much more consistent manner across these tests.

          Comment


          • #15
            Some of this is probably disk I/O. If some of these benchmarks are writing to disk files during the run, even just logging, that can cause problems. Windows I/O is all asynchronous by design. Writing to disk in the naive style used by most programmers and the default in most programming languages can often cause Windows to take multiple user <-> kernel round trips, in my experience.

            The Git benchmark is a big example of this. Git is dominated by file directory lookup, opens, reading for SHA1, etc. Linus wrote it while knowing exactly how Linux dentry cache works, so it takes full advantage. Windows has all this overhead with ASCII to UTF-16 case insensitive normalization, not to mention all of the checking it does for additional features like AV or indexing hooks (even if they aren't running) or checking to see if the file is remote and has to be synchronized via DFS. Or finding what device a drive letter actually points to in the NT kernel which has very little to do with Win32 / DOS.

            Really I think it's amazing Windows files work at all.

            Comment


            • #16
              I'm not surprised, on my i9-7900X when compiling using msvc2017 64b using jom for 100% CPU utilization (Qt project) mouse lags when moved from time to time. Debian and no such problem. I also have other issues with Windows, i.e. opening 10 Explorer windows lags @@, silky smooth on Linux. Could be motherboard issue, still investigating this, so can't say that behaviour on Windows is 100% M$ fault, but some update fixed my CPU-Z issue (running 20 threads produced worst result then running 18thread test @@ so that's that)
              Few years ago I had same problem with i7-4770 in both Debian and Windows (mouse lags on compilation) and there were patches for both Windows and Linux to address that issue. Seams like Linux guys did better job them multi billion company running close source proprietary code (shocker).
              Hope that patches that will come after this will also address my issues because sending mobo on my work PC is not something that I look forward to.

              Comment


              • #17
                Originally posted by Zan Lynx View Post
                Some of this is probably disk I/O. <snip>

                Really I think it's amazing Windows files work at all.
                Possibly... it would have been interesting to see CPU load graphs from those runs. If windows was properly scheduling things though it would likely have been able to overcome many those issues though buy raw CPU power... as obviously the git is a very parallelizable task.

                Last edited by cb88; 16 August 2018, 06:02 PM.

                Comment


                • #18
                  Originally posted by Zan Lynx View Post
                  Some of this is probably disk I/O. If some of these benchmarks are writing to disk files during the run, even just logging, that can cause problems. Windows I/O is all asynchronous by design. Writing to disk in the naive style used by most programmers and the default in most programming languages can often cause Windows to take multiple user <-> kernel round trips, in my experience.
                  Blender benchmark does not write to the disk at any time

                  Comment


                  • #19
                    Michael you should try windows server with the power governor set to "high performance" instead of balanced, windows server is known to push way lower cpu frequency if not all cores are utilized at least 65-70% and that is the reason why windows 10 outperforms windows server in your tests.

                    Comment


                    • #20
                      Originally posted by Michael View Post

                      Thanks, just my usual 100+ hour work weeks :/
                      And as usual we appreciate all you do!

                      Comment

                      Working...
                      X