Making the most of Apple Silicon power: 2 Core capabilities (2022) | Hacker News Reader

Making the most of Apple Silicon power: 2 Core capabilities (2022)

eclecticlight.co

102 pointsnateb202222 comments

Open articleView on HN

This is part 2 of a series of 7 articles. Navigation between the articles isn't super clear, so here's an index:

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...

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.

Additionally, Intel Thread Director only works under Windows 11 and whichever version of Linux that implemented support onwards.

Windows 10 and prior schedule in the blind, so to speak.

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.

You can force it to E core, using the taskpolicy command.

Here I use it to let my VM run in the background:

https://github.com/yoonsikp/vm_configs/blob/master/power_sav...

How much RAM do you account for this using (regardless of E core or not)?

This website has so many more great articles, and now there's a new one! I highly recommend reading the other ones about macOS internals.

Interesting read.

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.

But there's a far more limited amount of interactive tasks that you need to run right now at the highest speed.

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.

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.

EPYC SKUs with 3D cache also exist. Though I’m not 100% sure if it uses heterogenous chiplet approach that is seen in consumer RYZEN chips.

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.

No. Application with low priority will only be scheduled on efficiency cores regardless of how oversubscribed they are.

You can't set a process's processor affinity (aka which core(s) the process will execute on)?

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.

This is not exposed on production systems.

The link is dead.

Working here, and also now saved to wayback machine.

https://web.archive.org/web/20230722191544/https://eclecticl...

Reply on news.ycombinator.com