Announcement

Collapse
No announcement yet.

A Few Windows 10 vs. Ubuntu Linux OpenGL Benchmarks With A Core i7 7700K

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

  • A Few Windows 10 vs. Ubuntu Linux OpenGL Benchmarks With A Core i7 7700K

    Phoronix: A Few Windows 10 vs. Ubuntu Linux OpenGL Benchmarks With A Core i7 7700K

    This week I've published Windows 10 vs. Linux NVIDIA gaming benchmarks and a Radeon Software Windows 10 vs. RadeonSI/RADV Linux comparison with a variety of interesting games. For this third article on the topic of Windows 10 vs. Linux performance are a few Intel HD Graphics 630 benchmark results.

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

  • #2
    I wonder what is causing less FPS on linux, it seems that beyond driver implementation it is also something on mesa or the linux kernel itself that is causing the drop in fps when compared to windows.

    Comment


    • #3
      Why is windows indicated as the winner? Shouldn't ubuntu 16.10 be the winner with this test: http://imgur.com/a/ArYTy
      Last edited by iame6162013; 02-16-2017, 09:38 AM.

      Comment


      • #4
        Originally posted by TheOne View Post
        I wonder what is causing less FPS on linux, it seems that beyond driver implementation it is also something on mesa or the linux kernel itself that is causing the drop in fps when compared to windows.
        I'm guessing a big part is probably the scheduler.

        Comment


        • #5
          Originally posted by AndyChow View Post
          I'm guessing a big part is probably the scheduler.
          Has someone analyzed what is wrong with the scheduler for gaming loads? Has anyone tried to implement better scheduler (or tune current) and benchmarked that to prove this? I think these should be done to improve the situation, otherwise nothing will ever happen.

          Comment


          • #6
            Originally posted by Tomin View Post

            Has someone analyzed what is wrong with the scheduler for gaming loads? Has anyone tried to implement better scheduler (or tune current) and benchmarked that to prove this? I think these should be done to improve the situation, otherwise nothing will ever happen.
            BFS, but I have no idea of its current state and whether anyone benchmarked it already. Maybe Michael did.

            Comment


            • #7
              Originally posted by Tomin View Post

              Has someone analyzed what is wrong with the scheduler for gaming loads? Has anyone tried to implement better scheduler (or tune current) and benchmarked that to prove this? I think these should be done to improve the situation, otherwise nothing will ever happen.
              *waves*

              Here's the issue: The Linux scheduler (and most of the prominent replacements out there that are under development) are designed to be "fair" schedulers, which means that over a certain time period, all runnable threads in the system get a chance to run. This sounds good in theory, but not in reality.

              Here's the issue: Most games do about 60-70% of their total workloads across just two threads: The Main Executable thread, and the Main Rendering thread. The interruption of either tanks performance, as the interruption of one will usually lead to a stall of the second [in effect, the performance loss is polynomial to lost execution time, not linear]. So let's compare Windows to Linux in regards to thread scheduling:

              Windows: The golden rule of the Windows scheduler is a simple one: At any point in time, the highest priority runnable threads ALWAYS run. Now, there's a bunch of rules that affect priority (fullscreen app, how long the thread is running/waiting, and so on), but this rule is absolute. If you have a four core CPU, then the four highest priority runnable threads at any instant are the ones that are executing. From a schedule perspective, Windows doesn't really care about what CPU core threads run on; if a thread that is running on CPU 0 gets interrupted, and the lowest priority thread that is currently executing is on CPU 3, the thread will be re-assigned on CPU 3.

              This schema is great for running any singular application, especially exclusive fullscreen applications, as the application will get a disproportionate amount of runtime compared to the rest of the system. The downside is the rest of the system will suffer latency issues (Alt-Tab, opening/running other apps, etc) due to other applications having to fight for CPU time. In effect, Windows performance stalls out the more applications you try and run at the same time, as all the runnable threads constantly bump eachother, killing performance for all of them.

              Linux: Linux uses per-core run-queues. Essentially, the total processing load is tried to be split across all available CPU cores, and each thread will be guranteed to run within a certain timeframe. There's a few downsides to this approach, one of the more notable being that if a thread gets bumped, it can not be re-assigned to a different CPU core, even if said CPU core is currently idle, because of the per-core run-queues. Which from a performance perspective is NOT a good thing.

              So here's an overview of how this works in practice: The scheduler assigns threads to individual per-core run-queues. Your games primary two threads get assigned to Cores 0 and 1, along with several low-priority background system threads. Game starts, and the main rendering thread gets bumped by a background thread, causing it to stop for some period of time. Meanwhile, the main game engine running on Core 0 is sending data to the now not running thread on Core 1. Whoops, now that has to stop and wait. Performance tanked.

              This is why GPU benchmarks (which tend to be CPU light GPU heavy) tend to perform about the same between Windows and Linux, but game performance (much more sensitive to CPU performance) tend to show CPU bottlenecks on Linux, even though on Windows they all are GPU bottlenecks on the same CPU, That's the scheduler. It's costing Linux gaming performance close to 20-30% relative to Windows, increasing with the amount of threads in the system.

              Now, the Linux approach works great from a latency perspective; the system will remain snappy, as every task will get done in a timely manner, the UI will never lag, and all user input will be promptly handled. But from a "get one CPU intensive program done as fast as possible", the scheduler options for Linux are basically crap.

              Now, if you tried running two games side by side, Linux probably wins due to degrading more gracefully compared to Windows. But for a SINGULAR CPU INTENSIVE APPLICATION, the Windows scheduler is far superior.

              Comment


              • #8
                Originally posted by gamerk2 View Post

                *waves*
                seems like an issue with the games working threads and not the schedular perse.

                Comment


                • #9
                  @gamerk2
                  Interesting read. So, since Linux allows you to change schedulers, are you aware of any that are known to improve gaming performance?

                  Also I would like to point out that Mesa in general seems to be a little more CPU intensive than alternative drivers (and is locked to a single thread), which seems to support the scheduler issues you bring up.

                  Comment


                  • #10
                    Originally posted by gamerk2 View Post
                    snip
                    I doubt this is the case. Even Windows must give other threads running in the system a chance to execute within reasonable time. If it worked like you describe, Windows would effectively loose multitasking, meaning no networking, no sound, no uTorrent fetching you the latest episode of your favorite TV series while you're gaming, etc. Linux is probably more fair than Windows but unless you have multiple CPU-heavy tasks running at the time you play a game this greater fairness is very unlikely to account for the observed difference. What concerns me a lot more is that Michael ran all of his tests on a Kaby Lake CPU with the P-State CPU governor enabled. The P-State governor has been show by Michael himself to be troublesome with the Kaby Lake chips. Another round of benchmarks done on Skylake or with ACPI-CPUFreq governor used instead would be interesting.

                    Comment

                    Working...
                    X