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

[Aiua]

That's the scheduler. It's costing Linux gaming performance close to 20-30% relative to Windows

source?
Because it seems kind of impossible to me to be able to pinpoint how much difference is due to scheduling, without implementing another Linux scheduler which would behave like the Windows scheduler.

[johanb]

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.

There's a difference between slowing down due to a lower priority and starving, stop exaggerating.

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.

However I do agree, while CPU scheduling is important it shouldn't make such a huge difference on dual-threaded applications.

Would be great if Michael could bench DotA 2 on the NVIDIA and AMD binary blobs on Windows and Linux with both OpenGL and Vulkan. Tried to google on that but no hit. Would be interesting to see a bottlenecked (possibly underclocked) 4+ core CPU in a heavily threaded gaming workload (and possibly also with multiple schedulers to see how they behave)

[indepe]

It's costing Linux gaming performance close to 20-30% relative to Windows, increasing with the amount of threads in the system.

How did you arrive at this number? Are you able to test your theory? So far I have no information that would support such a large number.

EDIT: Also I was under the impression that Linux does migrate threads from one core to another (it doesn't seem necessary to do this very often in such a case).

[indepe]

P.S.: In my own tests with a very plain single-threaded command line app, the amount of performance loss due to interruptions which I can clearly attribute to interrupts and/or thread switches, is less than 2%, perhaps plus some amount due to resulting cache misses. And even that is reduced significantly when I switch the cpu freq governor from 'performance' to 'userspace' (with a fixed non-turbo frequency), as that reduces the amount of lengthy interruptions by a factor of 4.

So at least in those simple tests, there is no space to accomodate a number of 20-30%.

[marty1885]

Anyone try to boot a real time kernel and benchmark it for gamming?

[Almindor]

snip

As others have stated this is not the real case. Linux "more fair" scheduling can cause some slowdown but your numbers are blown out of proportion.
One way to test this tho is to assign the game process a high priority (nice -19) and see how it plays along and if you get such a huge performance difference.

Even if you say nice -19 won't get to windows level (which itself would be a doubtful statement) it should at least get 50% improvement from the "20-30%" you mention.

So if the perceived drop is say 10 FPS, you should see a +5FPS gain with nice -19 at least. I doubt that's the case.

[tenplus1]

I still think that using Unity desktop drops some FPS also, try benchmarking using a lighter Xubuntu or Lubuntu and see the difference.

[AsuMagic]

Anyone try to boot a real time kernel and benchmark it for gamming?

I doubt real time kernels are any good for gaming.

[Michael]

I still think that using Unity desktop drops some FPS also, try benchmarking using a lighter Xubuntu or Lubuntu and see the difference.

That's been tested many times before and modern Unity doesn't really have more overhead compared to other compositors.

[gamerk2]

Anyone try to boot a real time kernel and benchmark it for gamming?

Realtime Kernels would be absolute crap, as you take the issues I described and jack them up to 11.

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.

Windows does a LOT under the hood to dynamically adjust priorities. The main ones I know of:

1: Runnable threads that are not currently running get a priority boost.

2: Threads that are running receive a priority decrement.

3: Exclusive Fullscreen applications get a priority boost.

4: Minimized applications get a priority decrement.

And there's a lot more. Throw in the fact Windows doesn't care which cores a thread gets assigned to more or less ensures your game is running about as fast as it possibly can without interrupting the rest of the system.