#MACOS INTEL POWER GADGET CODE#

#MACOS INTEL POWER GADGET CODE#

And if you believe that, you drop the idea of offering the user control over QoS, and run all that app’s code at high QoS after all. The clear conclusion is that running these eight threads on the E cores was considerably less efficient than running them on the P cores.

On 8 E cores, an energy value of 194 was sustained for 40.4 s, giving a total of 7838 units.s, or 980 per thread.

On 8 P cores, an energy value of 800 was sustained for 6.6 s, giving a total of 5280 units.s, or 660 per thread.

What do you get in return? According to Activity Monitor’s Energy pane:

So there’s a big performance hit from constraining that code to the E cores. The results from the two different QoS settings are: To understand what they’re seeing, I used my app AsmAttic to run tests with different numbers of threads at the two extremes of QoS: 9 or ‘background’, which constrains the code to E cores, and the highest of 33, which runs the code preferentially on the P cores until they’re fully loaded, then uses available E cores as well.įor this introductory example, I use 8 threads of floating point maths on an M1 Max (in a Mac Studio), and a tight loop run 1 billion times in each thread. This article explains why, and its message is not to trust Activity Monitor over CPU or Energy figures.

In many cases, these appear to demonstrate that running code exclusively on E cores uses more energy, not less. As more developers are looking at giving the user control over which cores do the heavy lifting in their apps, when running on M1 Macs, they’re puzzling over contradictory figures given by Activity Monitor.

Macos intel power gadget