While you can't explicitly allocate a process to E cores, I wonder if you'd be able to make a program which floods high QoS processes to saturate E cores until they are full and then launch the desired application into a P core
This is a similar hack to what AMD does with their new 3D-series processors with two CCDs (or clusters following this article's terminology). One of them has a higher clock count but the other one has much more L3 cache. Since their target is gamers (at least at the consumer level chips), they basically ship a driver which detects when you launch a game and "parks" the low-cache CCD from being assigned tasks which effectively dispatches your processes to the high-cache ccd.
I don't think it's completely guaranteed that you can choose such things anymore. Some scheduling work has to be done at the hardware level and it's certainly going to be hijacked as heterogeneous CPU micro architecture becomes more pervasive and the gulf of difference in feature set between efficiency and performance cores becomes wider.
I'm not sure I see the point? Applications generally run on P cores by default; there's no need to go through those sorts of gymnastics to make that happen.
On my M2 Macbook Air, I see everything generally executes on the E-cores. The P-cores only see load when there's clearly something that needs lots of processing power.
I presume there's logic in the scheduler to prioritize E-cores for battery life purposes.
I wonder what went into the decision on the ratio of P to E cores. Naively it seems like more of the die space should be dedicated to E cores since they're so killer for workloads where efficiency or throughput matter. Obviously some jobs can't spread the load across multiple threads and are sensitive to single-threaded latency, but those workloads won't benefit from so many P cores anyways.
There’s only so many background / non-interactive tasks you need to run, and especially that you need to run now: with more Es you increase the parallelism but if everything goes idle quickly you’ve kinda wasted the silicon.
P cores are more relevant for interactive work which the user is waiting on, hence he sacrifice if efficiency.
However when there are interactive tasks to run, you need to run them now, because the user is waiting.
That is why I find Intel's core mix dubious. By definition background tasks are not generally time-critical, having more cores for them doesn't usually save me time, or money.
1, is incorrect in the last paragraph about Intel Thread Director.
The hardware classifies every thread context into one of 4 classes and provides the OS with dynamic perf/power values for all cores. It's the Windows thread scheduler that makes the final decision just like on mac but can make use of the additional hints from the CPU for doing a better job.
I'm lost on how a CPU would schedule workload when most of the information is stored in OS's process/thread structures that aren't shared with the firmware/p-code and it's supposed to work with multiple platforms.
Yup; well that's because Microsoft has extremely high bar for backporting feature requests. In thread director's case, the missing functionality isn't a deal breaker for the types of systems restricted to Win 10.
23 comments
[ 2.3 ms ] story [ 70.8 ms ] threadhttps://web.archive.org/web/20230722191544/https://eclecticl...
I presume there's logic in the scheduler to prioritize E-cores for battery life purposes.
Here I use it to let my VM run in the background:
https://github.com/yoonsikp/vm_configs/blob/master/power_sav...
I wonder what went into the decision on the ratio of P to E cores. Naively it seems like more of the die space should be dedicated to E cores since they're so killer for workloads where efficiency or throughput matter. Obviously some jobs can't spread the load across multiple threads and are sensitive to single-threaded latency, but those workloads won't benefit from so many P cores anyways.
P cores are more relevant for interactive work which the user is waiting on, hence he sacrifice if efficiency.
That is why I find Intel's core mix dubious. By definition background tasks are not generally time-critical, having more cores for them doesn't usually save me time, or money.
1. "M-series chips are different" https://eclecticlight.co/2022/10/03/making-the-most-of-apple...
2. "Core capabilities" https://eclecticlight.co/2022/10/05/making-the-most-of-apple... (this one)
3. "Controls" https://eclecticlight.co/2022/10/13/making-the-most-of-apple...
4. "Frequency" https://eclecticlight.co/2022/10/17/making-the-most-of-apple...
5. "User control" https://eclecticlight.co/2022/10/20/making-the-most-of-apple...
6. "Empowering users" https://eclecticlight.co/2022/10/24/making-the-most-of-apple...
7. "Virtualisation and core use" https://eclecticlight.co/2022/10/27/making-the-most-of-apple...
The hardware classifies every thread context into one of 4 classes and provides the OS with dynamic perf/power values for all cores. It's the Windows thread scheduler that makes the final decision just like on mac but can make use of the additional hints from the CPU for doing a better job.
I'm lost on how a CPU would schedule workload when most of the information is stored in OS's process/thread structures that aren't shared with the firmware/p-code and it's supposed to work with multiple platforms.
Windows 10 and prior schedule in the blind, so to speak.