Darth Ender
Gawd
- Joined
- Oct 11, 2018
- Messages
- 543
https://openbenchmarking.org/result/1908234-HV-1908220HV55&obr_nor=y&obr_hgv=3900x0.1+8-22-19
So many other setting changes didn't even make it on that test run.
All the tweaking and changes amount to basically no change in performance, but do impact heat output significantly.
Where your processes get assigned when you run them has to do with the operating system process scheduler (the kernel). It would have to be updated to be aware of the heterogeneous distribution of core capability in modern (zen2 and beyond) cpus. I assume there's some identifier in the cpu of these golden cores ...either that or these programs are assigning identifiers based on just whichever shows the highest frequency in some initial test it makes. Either way, the kernel has to be specially coded since nothing like this has existed before on x86.
ARM has something similar, where they have high perf cores and low perf cores and the kernel uses a kind of power management scheduler setup to decide when to push processes to the high powered cores (however that's linux, not windows) . A similar system could be setup for x86 though.
I wouldn't expect windows or even linux to put a lot of work into doing this until Intel jumps on board with individual core binning .. and if they have and just haven't been very vocal about it, then it would need to get much more common and impactful to performance to justify the effort.
The motherboard bios/firmware/agesa and cpu have absolutely nothing to do with how processes get assigned to cores to run. Nothing in any future update will change that.
For now, it seems seeing that cpu core hit 4.55Ghz rather than 4.3 or 4.2 is more for bragging rights than it is for serious boosts to single thread application performance. Basically eye candy for hardware enthusiasts and benchmark reviewers.
Until then, you'll have to manually pin processes you want to definitely run on the fastest core(s) yourself after identifying which ones those are everytime you run the application.
this can be done in the windows task scheduler for cpu affinity ... and in linux via taskset -c <core number> and either the command or pid of a running one
So many other setting changes didn't even make it on that test run.
All the tweaking and changes amount to basically no change in performance, but do impact heat output significantly.
Where your processes get assigned when you run them has to do with the operating system process scheduler (the kernel). It would have to be updated to be aware of the heterogeneous distribution of core capability in modern (zen2 and beyond) cpus. I assume there's some identifier in the cpu of these golden cores ...either that or these programs are assigning identifiers based on just whichever shows the highest frequency in some initial test it makes. Either way, the kernel has to be specially coded since nothing like this has existed before on x86.
ARM has something similar, where they have high perf cores and low perf cores and the kernel uses a kind of power management scheduler setup to decide when to push processes to the high powered cores (however that's linux, not windows) . A similar system could be setup for x86 though.
I wouldn't expect windows or even linux to put a lot of work into doing this until Intel jumps on board with individual core binning .. and if they have and just haven't been very vocal about it, then it would need to get much more common and impactful to performance to justify the effort.
The motherboard bios/firmware/agesa and cpu have absolutely nothing to do with how processes get assigned to cores to run. Nothing in any future update will change that.
For now, it seems seeing that cpu core hit 4.55Ghz rather than 4.3 or 4.2 is more for bragging rights than it is for serious boosts to single thread application performance. Basically eye candy for hardware enthusiasts and benchmark reviewers.
Until then, you'll have to manually pin processes you want to definitely run on the fastest core(s) yourself after identifying which ones those are everytime you run the application.
this can be done in the windows task scheduler for cpu affinity ... and in linux via taskset -c <core number> and either the command or pid of a running one