3 ms·

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

by api 8y ago

cptskippy 8y ago
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.
- api 8y ago
  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.
  - cptskippy 8y ago
    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-patch-tested 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.
- mmrezaie 8y 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?
  - cptskippy 8y ago
    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-next.git/commit/?id=051f3ca02e46432c0965e8948f00c07d8a2f09c0 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.
ksec 8y ago
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?
- rbanffy 8y ago
  Because 10% of their used base is about the same size as a first-world country.

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

by api 8y ago

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.

api 8y ago
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.
- cptskippy 8y ago
  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-patch-tested 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.
mmrezaie 8y 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?
- cptskippy 8y ago
  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-next.git/commit/?id=051f3ca02e46432c0965e8948f00c07d8a2f09c0 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.

ksec 8y ago

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?

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