Threadripper 3970X Performing Better On Windows Relative To Linux - Thanks To Microsoft Or Zen 2?

[phoronix]

Phoronix: Threadripper 3970X Performing Better On Windows Relative To Linux - Thanks To Microsoft Or Zen 2?

With the AMD Ryzen Threadripper 3970X benchmarks on Windows 10 and Linux, Ubuntu 19.10 and other common distributions were just ~2% faster than the Microsoft OS and Clear Linux was just ~10% faster, based on 80+ benchmarks carried out. Those margins are much closer than we have seen with past iterations of Threadripper, but is that due to the Zen 2 microarchitecture and the improved topology of the new Threadripper CPUs or due to Microsoft's scheduler changes and other software improvements made in Windows 10 November 2019 Update? Here are some benchmarks...

http://www.phoronix.com/scan.php?page=news_item&px=3970X-Follow-Up-Win-Linux

[eydee]

Title:
Threadripper 3970X Performing Better On Windows Relative To Linux...

(So windows is faster.)


1st sentence:
With the AMD Ryzen Threadripper 3970X benchmarks on Windows 10 and Linux, Ubuntu 19.10 and other common distributions were just ~2% faster than the Microsoft OS and Clear Linux was just ~10% faster, based on 80+ benchmarks carried out.

(So Linux is faster.)

So which one?

[abott]

Title:
Threadripper 3970X Performing Better On Windows Relative To Linux...

(So windows is faster.)


1st sentence:
With the AMD Ryzen Threadripper 3970X benchmarks on Windows 10 and Linux, Ubuntu 19.10 and other common distributions were just ~2% faster than the Microsoft OS and Clear Linux was just ~10% faster, based on 80+ benchmarks carried out.

(So Linux is faster.)

So which one?

"It depends." Isn't a bad answer. So which one?

[polarathene]

Would be interesting to see why Windows is doing that much better with things like 7-zip, is it just due to the CPU being new and a future kernel will improve on that while Windows got priority support from AMD before Linux? If you did a similar benchmark with an older generation threadripper, that should give some insight on that?

Otherwise I'm sure Linux could be configured to perform better, even if you only want to test distro defaults, it'd be neat to know the why and what can be done on Linux to get comparable/better results than Windows(which afaik isn't as flexible tuning wise?)

[edwaleni]

Would be interesting to see why Windows is doing that much better with things like 7-zip, is it just due to the CPU being new and a future kernel will improve on that while Windows got priority support from AMD before Linux? If you did a similar benchmark with an older generation threadripper, that should give some insight on that?

Otherwise I'm sure Linux could be configured to perform better, even if you only want to test distro defaults, it'd be neat to know the why and what can be done on Linux to get comparable/better results than Windows(which afaik isn't as flexible tuning wise?)

Actually there are later builds of the zip tool for Windows that take advantage of new Intel instructions. But they still haven't been ported over to the Linux version.

I have pinged several college groups to see if they would take a donation to compile an updated Linux version but no joy so far. At the moment there is a 3 release gap between the OS versions.

[smitty3268]

It's primarily because Windows chokes with NUMA support, and the new chips default to a single NUMA node rather than 4 like the 2990wx did.

[GreenReaper]

So which one?

The title is misleading. Windows is performing better than it was before relative to Linux, but it is still slower than Linux

[some_canuck]

does agesa factor into the increase at all?

[edwaleni]

I have spent several hours scraping around looking for some technical reason for the performance change from the MSFT side and I can't find any.

The only thing I found is that MSFT now "pre-loads" future features into their updates and then sends a "feature update" KB sometime down the road to activate them.

If the feature update fails in one of the test rings, then the KB to activate it isn't sent.

I am aware that MSFT is changing the way they handle NUMA for a future Intel CPU release, but its not even at the ring level yet.

The next thing to look at would be what version of CPU driver was in the first test and what one was in the second test and see if it had any bearing. In my experience, I have not seen much variance at this level, only at the OS HAL. Custom HAL's are not as common as they were back in the early days of NT Server due to the proliferation of cores in a single socket.

Since the Windows team is organized differently now I don't know how much of the OS is segregated in its development anymore.

I will keep nosing around to see what I can find, but at my last look the 1909 release was supposed to be primarily visual & functionality changes, not performance. But with this new rollout strategy, the changes could have come out several updates ago and were simply "activated" by the 1909 feature release KB.

[torsionbar28]

It's primarily because Windows chokes with NUMA support, and the new chips default to a single NUMA node rather than 4 like the 2990wx did.

Seems like the most logical answer to me. NUMA sucks on Windows, so makes perfect sense that reducing the number of nodes would yield better performance in Windows OS.