Hacker News Reader

Comment by Jhsto | Hacker News Reader

"Not only Youtubers test on Windows, virtually the whole tech reviewer community tested on Windows exclusively. And many concluded that Threadripper problems were due to memory problems, and only few blamed Windows for it."

https://www.phoronix.com/forums/forum/phoronix/latest-phoron...

Still, over 2x increase in performance on Linux over Windows seems insane.

View on HN

Windows is the first thing I blame ;-)

In this case, it looks like the thread scheduler is trying to do something clever that doesn't quite work well with this specific CPU. Maybe it's improperly localizing threads to cores or causing more cache evictions than it should. Without seeing performance counters it's hard to guess.

My guess would simply be the scheduler doesn't have knowledge of the NUMA architecture of the processor, and cannot therefore efficiently schedule tasks to avoid large memory access costs.

One can confirm this which sounds true by profiling the benchmark tools on windows and Linux specifically, remote page loads and such.

The firmware has long made the NUMA topology available to the OS through ACPI tables.

Has a NUMA topology like this ever been used with Windows? They could be misinterpreting it. They have quite a reputation for partial buggy implementations of ACPI-related stuff that end up becoming de-facto standards.

I think it's less a matter of misinterpreting the topology, and more that the Windows scheduler isn't prepared to handle the somewhat exotic topology; whereas the Linux scheduler seems to be more intelligent about handling the memory-less NUMA nodes.

Memory-less NUMA nodes are present on the Xeon Phi (all non-HBM is on that node), so that looks like a good explanation. I don't think Windows can handle it.

Windows Server is designed to deal with NUMA systems and Windows 10, being a consumer OS, is not, so the comparison is outright faulty. The Phoronix reviewer even acknowledges that Windows Server benchmarks are planned for the future.

IIRC, they run on the same kernel with different licensing enforcement. And this is not a server CPU, at least as much as Windows 10 is not a server OS, meaning that it's not marketed as such.

AMD engineers are the first thing that I blame. How did they not notice the bottleneck? Also, I am pretty sure that top engineers at companies like AMD and Nvidia have access to Windows source code so they can test performance and submit fixes/patches. AMD has lesser marketshare so it's right for Microsoft to focus their code on Intel CPUs unless AMD reports issues.

Considering that their terrible GPU drivers got me off AMD GPUs and into the waiting arms of Nvidia, color me not surprised.

I don't necessarily think so. Why does Linux work better? Does Linux do some magic stuff? Or is there some bug in the Windows Kernel/Scheduler? If so, then it's not AMD to blame.

Assuming this issue is because Windows hadn't really expected to work with memoryless NUMA nodes I gotta say, I agree with you.

These companies have working business relationships with each other. I'm sure MS is fairly responsive on these sorts of things. AMD should probably have caught this in their internal development and getting Windows on board seems obvious?

There are reasons why it is called the WinTel alliance. Fortunately Linux dominate the server market now, hopefully this will give AMD some breathing space.

Never ascribe to conspiracy what can equally well be explained by stupidity... or in this case a broken scheduler.

Broken or optimized for a different set of processors?

Don't forget that AMD can submit changes directly to the Linux Kernel but has to request or help Microsoft to make changes to Windows.

Oh I'm sure they're optimized for Intel, but that's easily explained by Intel's near-monopoly for the past 10 years. Now that AMD is gaining market share again we'll probably see this change. MS doesn't want to look bad in benchmarks.

We saw a similar situation when AMD released the Bulldozer line of CPUs and it took a minute for Microsoft to release a Hot Fix to address the issue.

https://www.anandtech.com/show/5448/the-bulldozer-scheduling...

The reality is that Windows doesn't recognize the new CPU and so it's not using a scheduler optimized for it. Where as AMD could have upstreamed any necessary changes for Linux to fully support it months ago.

And also we should keep in mind that in Kernel level improvements, Linux by far is agiler than Windows. Windows process scheduler does not have fairness for ages now. When was CFS was added to Linux? a decade?

Linux isn't free of performance regressions with new architecture. There were patches last year to better support Epyc's NUMA.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...

It just seems that Linux avoided any regressions this year but Microsoft didn't.

I wouldn't call it a conspiracy. But why would M$ optimise for NUMA, or AMD when 90% of their use cases and customer have no use of it?

Because 10% of their used base is about the same size as a first-world country.

There's some additional interesting stuff in the comments. edwaleni points out that the Phoronix Test Suite uses a very outdated 7-Zip (16.02) and the current Windows client (18.05) includes a lot of changes since then.

https://www.phoronix.com/forums/forum/hardware/processors-me...

Reply on news.ycombinator.com