conciselyverbose@sh.itjust.works
on 10 Aug 2024 23:30
nextcollapse
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:
SomeoneSomewhere@lemmy.nz
on 11 Aug 2024 05:40
nextcollapse
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?
schizo@forum.uncomfortable.business
on 11 Aug 2024 01:37
nextcollapse
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
threaded - newest
🤦‍♀️
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.
It’s an easy fix, sure.
But there are 3 manufacturers for them to schedule for. It should be ready way before anything ships.
Copilot and ads taking up development cycles
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:
Microsoft Chose Profit Over Security and Left U.S. Government Vulnerable to Russian Hack, Whistleblower Says
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?
it’s obviously a scheduler/p-state bug in windows, look at the Linux performance
www.phoronix.com/review/ryzen-9600x-9700x
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
.