During the course of our testing, we observed that Windows 11 was scheduling workloads on the 9700X in a manner that would try to saturate a single core first, by placing workloads on each of its logical threads.
Actually, yeah, probably. CPU scheduling isn't the shiny new thing, nor something that gets that sweet, sweet monthly recurring revenue. So, it doesn't get prioritized.
Microsoft always operates like this. Whatever bullshit management demands for marketing purposes takes the resources away from basic stability and quality improvements. Sometimes this results in quite predictable disaster:
There should be no need for tuning, tweaking, or optimizing on functionality this basic.
If you ask the processor, it will spit out a graph like this telling you what threads/cores share resources, all the way up to (on large or server platforms) some RAM or PCIe slots being closer to certain groups of cores.
For values of "new chips" that include 20 year old ones. Foster was released 2001, the chips were single-core but you could have up to eight on a board so it's still multi-core SMT. First on-die multi-core SMT seemed to have been Paxville, 2005.
Or maybe Windows server has a proper scheduler and they never bothered bringing it to desktops?
This is shockingly stupid. SMT has been a thing on x86 long enough for it to be able to buy it's own alcohol and yet somehow the windows scheduler STILL can't fucking deal with it?
I'm not a kernel-level developer or anything but I mean, at some point you have to wonder how fucking trash windows kernel internals are that this problem keeps happening over and over and over and.....
Or they just found out that Windows process scheduler is still broken beyond repair. If you look at the benchmarks on GNU/Linux performance is all there. For example see Phoronix benchmark
11 Comments
conciselyverbose@sh.itjust.works · 71 pts · 2y
🤦♀️
jlh@lemmy.jlh.name · 58 pts · 2y
it's obviously a scheduler/p-state bug in windows, look at the Linux performance
https://www.phoronix.com/review/ryzen-9600x-9700x
adarza@lemmy.ca · 31 pts · 2y
so, basically, the os isn't tuned for the new chips yet.
the 2nd threads on smt-enabled cores are supposed to get hit last.
conciselyverbose@sh.itjust.works · 25 pts · 2y
It's an easy fix, sure.
But there are 3 manufacturers for them to schedule for. It should be ready way before anything ships.
ag10n@lemmy.world · 63 pts · 2y
Copilot and ads taking up development cycles
catloaf@lemm.ee · 15 pts · 2y
Actually, yeah, probably. CPU scheduling isn't the shiny new thing, nor something that gets that sweet, sweet monthly recurring revenue. So, it doesn't get prioritized.
floofloof@lemmy.ca · 2 pts · 2y
Microsoft always operates like this. Whatever bullshit management demands for marketing purposes takes the resources away from basic stability and quality improvements. Sometimes this results in quite predictable disaster:
Microsoft Chose Profit Over Security and Left U.S. Government Vulnerable to Russian Hack, Whistleblower Says
SomeoneSomewhere@lemmy.nz · 13 pts · 2y
There should be no need for tuning, tweaking, or optimizing on functionality this basic.
If you ask the processor, it will spit out a graph like this telling you what threads/cores share resources, all the way up to (on large or server platforms) some RAM or PCIe slots being closer to certain groups of cores.
barsoap@lemm.ee · 3 pts · 2y
For values of "new chips" that include 20 year old ones. Foster was released 2001, the chips were single-core but you could have up to eight on a board so it's still multi-core SMT. First on-die multi-core SMT seemed to have been Paxville, 2005.
Or maybe Windows server has a proper scheduler and they never bothered bringing it to desktops?
schizo@forum.uncomfortable.business · 64 pts · 2y
This is shockingly stupid. SMT has been a thing on x86 long enough for it to be able to buy it's own alcohol and yet somehow the windows scheduler STILL can't fucking deal with it?
I'm not a kernel-level developer or anything but I mean, at some point you have to wonder how fucking trash windows kernel internals are that this problem keeps happening over and over and over and.....
JRepin@lemmy.ml · 35 pts · 2y
Or they just found out that Windows process scheduler is still broken beyond repair. If you look at the benchmarks on GNU/Linux performance is all there. For example see Phoronix benchmark
MishMash@lemm.ee · 0 pts · 2y
drbluefall@toast.ooo · 1 pts · 2y