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

[JeansenVaars]

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.

might be off topic but how IO is handled on VirtualBox when running linux on windows??

[RomuloP]

might be off topic but how IO is handled on VirtualBox when running linux on windows??

I'm quite sure VirtualBox heavily cache IO operations, avoiding touching the real disk.
Windows do have a scheduler as you can see in here, it has a queue and IO priority levels, sure, it is a primitive scheduler but is a scheduler.

[F.Ultra]

- 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)

All the sources are available so why don't you show the patches that Ubuntu introduced to make their things slower? Should be dead easy and would be actual evidence.

[angrypie]

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.

On the other hand, using Windows is like riding a unicycle with a backpack. I'm sure you can get used to it, and it takes you everywhere, but it's uncomfortable, makes you tired and you look like a clown.

(On a more serious note: I don't think Windows was ever seriously rewritten to take advantage of multiple cores/threads or faster IO, probably because it would break backwards compatibility really badly.)

[gregzeng]

> " ... (There weren't Ubuntu 18.04.2 LTS results for Geekbench due to a simple oversight.)"
This suggests that Phoronix tests are run only once. Hopefully if the test is run several times, there is not too much deviation between test results.

Glad you described the bench results in percentages this time. Telling lies with graphical presentations is so easy. It would be nicer also to give more reports of generalized results. So I'll try to do this myself.
As expected, the later versions of the operating systems (Windows & Ubuntu) gave better results than the older version. However the speed difference between the two Windows versions may not be statistically significant.

The other "warning" is that the 18.04 version of Ubuntu is "Long Term Support" (LTS). By deliberate intention, it is optimized for stability, rather than benchmarks. Some of the "improvements" in version 19.04 will be included into the next LTS, version 20.04, as usual.

Ubuntu benchmarks can be further improved by using the "low-latency" version of the official Ubuntu kernels, and then again using the very latest versions, installed very deliberately. Absolute speed freaks might try compiling the original source code of the Linux kernel, optimizing the process for speed alone.

Good news in these Phoronix tests is that the bulk of Linux operating systems are based on both Debian, including Ubuntu family of operating system. After Debian (3 different versions), Ubuntu-core is the most popular base for all the hundreds of Linux operating systems. So if the user wants speed, plus access to third-party, closed source codecs, they should choose any of the Linux systems based on the Ubuntu-core.

Most desktop computer users statistically agree that Linux is generally a poor choice: lack of good applications, plus an overall lack of applications in general. However if the computer operating system is used for just a few applications for which Linux has available, perhaps the Ubuntu-based operating systems might be suitable.

Linux on the desktop soon might be ready for general use. When the mess between appimage, snap & Flatpak is sorted, perhaps the application coders for Windows will start coding for the one Linux package-type, as well.

[duby229]

I'm quite sure VirtualBox heavily cache IO operations, avoiding touching the real disk.
Windows do have a scheduler as you can see in here, it has a queue and IO priority levels, sure, it is a primitive scheduler but is a scheduler.

That's not a scheduler, It's much more like a time slicer.

[duby229]

might be off topic but how IO is handled on VirtualBox when running linux on windows??

The windows kernel will read IO just like I described, context switches and all, but the linux kernel in the virtual machine will handle it's own memory the way it does.

If you want to have a good visual representation, then look at bar graphs comparing linux apps on linux vs windows wsl. You can see the affectall that context switching has on IO.

[RomuloP]

That's not a scheduler, It's much more like a time slicer.

Well a FIFO based scheduler is a lot simpler and is taken as a scheduler. Sure, Windows IO scheduler is primitive (a priority scheduler in fact), but is a scheduler.

[duby229]

Well a FIFO based scheduler is a lot simpler and is taken as a scheduler. Sure, Windows IO scheduler is primitive (a priority scheduler in fact), but is a scheduler.

No it's really not, it's a time slicer. It doesn't "schedule" anything, it allocates slices of time and literally nothing else. It has no way at all to prioritize anything, it simply allocates time. It gives slices of time to IO loads and nothing else. It's doesn't schedule anything, there is no kind of queue, no kind of buffering system, no kind of scheduler, no kind of abstraction at all. It just allocates time and nothing else. It then spends most of that time flushing and filling the CPU integer pipelines due to constant serial streams of context switches.

[RomuloP]

No it's really not, it's a time slicer. It doesn't "schedule" anything, it allocates slices of time and literally nothing else. It has no way at all to prioritize anything, it simply allocates time. It gives slices of time to IO loads and nothing else. It's doesn't schedule anything, there is no kind of queue, no kind of buffering system, no kind of scheduler, no kind of abstraction at all. It just allocates time and nothing else. It then spends most of that time flushing and filling the CPU integer pipelines due to constant serial streams of context switches.

I already pointed an oficial link about how their scheduler work, its all there, if you want you can give a deeper look at their API, a good start is GetQueuedCompletionStatus(), or maybe apparently you know better than MS about Windows internals and they talking about the IO queue is a lie? Most probable that your knowledge about Windows stopped in XP era.

I will even help and post a link to documentation:
https://docs.microsoft.com/en-us/win...mpletionstatus

Also there is a reference in wikipidia about Vista IO scheduler, as I said, a Priority Scheuduler:
https://en.wikipedia.org/wiki/Schedu...uting)#Windows

The wiki page points to a deeper article about the subject by Gabe Frost:
https://en.wikipedia.org/wiki/Schedu...g)#cite_ref-11