For the last nine years, Apple silicon chips in iPhones and iPads, and most recently Macs since 2020, have had Efficiency cores, designed to eke out their use of power to extend battery time and stay cool. Although you have no control over what runs on the Efficiency cores in a device, there are options for Macs. This article explains how you can reduce energy use in an Apple silicon Mac, and why that’s a good idea.

M series chips can have between 2 and 8 E cores, each with slightly less than half the processing power of their Performance core equivalent. If you’re unsure how many CPU cores of each type your Mac has, and how they’re used, open the CPU History window in Activity Monitor and watch.

Particularly in the first few minutes after starting a Mac up, the E cores will be busy catching up with their housework, routine tasks such as updating Spotlight’s indexes, checking for various updates, and making an initial backup. Once those are out of the way, you’ll see other bursts of activity, such as XProtect Remediator scans, and a steady trickle of background tasks. Because most user processes are run on the P cores, even hectic E core activity has no effect on what you’re doing.

When threads run on the E cores, they run more slowly, take longer to complete, and for all that take substantially less energy and power. That’s because those cores are designed to be more energy-efficient and are run at lower frequencies, or clock speeds. For almost any given task, running its threads on E cores will thus use less total energy, and

• run a laptop Mac’s battery down less,
• generate less heat, so keep the Mac cooler,
• leave the P cores free for more pressing work.

In-app controls

Although the code run by apps can’t be directly allocated to P or E cores, macOS can get a strong hint by a setting known as the Quality of Service (QoS). By default, the whole of a user app will normally be run at high QoS, and macOS will try to do that on P cores, so long as they’re available.

Some apps are starting to give the user control over this in a ‘speed control’. Among those is the compression utility Keka.

In Keka’s settings, you can give its tasks a maximum number of threads, and even run them at custom Quality of Service (QoS) if you want them to be run in the background on E cores, and not interrupt your work on P cores. Although you’re unlikely to do this when compressing or decompressing a few small files, when its tasks are likely to take several minutes, and you can afford to wait a little longer, run them on the E cores.

Two of my apps, Dintch and Cormorant, have even simpler controls.

Dintch has a three-position slider, offering

• a red racing car for top priority on P cores when possible;
• a blue truck for medium priority on P cores when possible;
• a green tortoise for the E cores.

The first two of those took 6.2 seconds to check a 16.8 GB file, and the third took almost 25 seconds. The difference between the first two is in their priority, if there are several threads competing for the same CPU cores. If you’re waiting for files to be checked in Dintch, set the speed control at the racing car, but if you can leave the Mac to get on with checking in the background and want the efficiency of E cores, set the control to the tortoise instead.

Cormorant, a much simpler compression utility aimed at AirDrop transfers, has a fourth slider position with a pointing hand that allows you to set a custom number of threads and QoS level, as I also use that to test and compare P and E cores.

Activity Monitor

You can observe the effects of these controls in Activity Monitor’s CPU History window.

Here’s the window after Dintch has checked that 16.8 GB file with the setting for the racing car. All the P cores show four bursts of activity as they run the code to compute the SHA256 digest.

When set to the tortoise, there’s almost no activity on the P cores, but the four E cores are busy computing for nearly 25 seconds.

One word of caution about over-interpreting what you see in the CPU History window. Both P and E cores can run at a wide range of frequencies, but Activity Monitor takes no account of that. Taken at face value, you might think these E cores were working far harder than the P cores, but in fact they were only running at low frequency, little more than idle. In contrast, those small bursts of P core activity were at higher frequency, so were using far greater energy and power, albeit more briefly.

Other apps

I’m sure that other apps are offering the user control over whether their longer tasks are run on the E cores, and will be pleased to learn of them. There are also two ways that you can control them yourself, using St. Clair Software’s excellent utility App Tamer, or the command tool taskpolicy.

App Tamer works best with apps, and makes it simple to demote their threads so they’re run on E cores in the background. If you want to demote the threads of a running process from Terminal, use a command like
taskpolicy -b -p 567
to confine all threads of the process with PID 567 to the E cluster. You can then reverse that using the -B option for threads with higher QoS, but can’t alter those set to a low QoS by the process. The ground rule here is that high QoS threads can be demoted to the E cores, but low QoS threads can’t be promoted to run on the P cores.

What to avoid

Running a virtual machine on an Apple silicon Mac always uses P cores first, even though they will also be used to run background threads inside the VM. So the worst thing you can do in terms of energy efficiency and core use is to run code inside a VM.

Summary

• Run task threads on E cores for better battery endurance, lower heat production, and to keep other apps more responsive.
• Where an app provides a control, use it to run long tasks in the background, on the E cores.
• For apps that don’t, use App Tamer. For processes use the taskpolicy command tool.
• Avoid running a VM if you want high efficiency.