The number given as % CPU in Activity Monitor
eclecticlight.co
eclecticlight.co
Does "%CPU" need to take into account these things?
I think if I had to pick a single number for reporting CPU usage it would be percent of available throughout. Although this has complications (the max frequency will depend on external conditions like temperature). But 0% would mean "no runnable tasks" and 100% would mean that the CPUs are running at the maximum currently available speed. The values in-between would be some sort of approximation but I think that is fine.
In general, understanding how much "compute capacity" you still have left is very much an experimental science with modern CPUs.
As an example of what I mean, MacBook Airs had exactly the same cores as MacBook Pros (up to 13" Pros iirc), but while you could max out one or two cores on both (and get "200% usage" that is comparable), going past that would mean entirely different things due to one being passively cooled.
With x64 platforms, TDP discussion is even more relevant even without getting to ARMs big.SMALL or Intel's P/E core distinction.
That said, it's not particularly easy to apply these corrections, especially because the available maximum clock speed depends on variables like the ambient temperature, how bust all the cores are, and how long the CPU has been boosting for. So if you were to apply these corrections, either you report that a fully loaded system is using less than 100% of possible available CPU power in a lot of cases, or your correction factors vary over time and are difficult to calculate.
I don't think the theoretical maximum clock speed is relevant to a %CPU measurement, for two reasons. First, as you note, it's subject to a lot of things that the user generally has no control over. Second, I suppose %CPU is meant to be a measure of current/real/instantaneous load -- what is, rather than what could be.
https://devblogs.microsoft.com/oldnewthing/20210629-00/?p=10...
Often you don't care that the current batch of processes are using 100% of what the CPU cores they are assigned to can do at current clock rates, what you want to know is how much is left available, so you can add more work without slowing any existing tasks down much.
It used to be, back when CPUs didn't have low & high power cores and always ran what they had at the same speed, that %CPU shown in various OS displays was a reasonably accurate measure of the impact of a process that could easily be used to judge optimisation success (getting the same done in less hardware effort) and scaling success (getting the same done in less wall-clock time by giving more hardware to the problem or improving parallelism to make better use of what you already have).
These days it is more complicated than most assume at face value, and you have to be a lot more careful when assessing such things to avoid incorrect assumptions leading to wrong decisions. It would be nice to get back to the previous state of affairs, in terms of a given % value meaning something more fixed. Of course that is not as practical to achieve as naively stating the problem might suggest: for a start you can't really state what 100% is because in many cases the maximum clock might only be achievable for very short periods before thermal throttling kicks in. Maybe if there is a “minimum maximum”, below which we know the throttle won't go, we could state that as 100% and display more when the heat limit is not taking effect, but I expect that really would confuse end users (I have memories of confused conversations when multi-core CPUs became common, when people saw displays of processes using ~200%, with that meaning ~100% of ~2 cores).
I at least found the article interesting, and learned something useful from it.
(extreme numbers to highlight the point)
(Is it the hardware that is broken? Software? Firmware? User configuration? Cooling? Power? Is it beyond your paygrade to make this determination?
In any or all cases, and at any clock speed: At 100% utilization, it is doing as much work as it can within the constraints of the operating environment in which it exists; one can't squeeze an extra instruction in edgewise without it getting in the way of existing work.
And no, perhaps displaying utilization as 100% won't help you at all with identifying and correcting the issue.
But the alternative of displaying utilization as 0.00000001% won't help you with that, either.)
That is: if we simplify the case to a single core laptop which has 2 power states: laptop plugged into wall, it has a min freq of 1Ghz and a max freq of 2Ghz. If on battery, it has a min freq of 500MHz and a max freq of 1Ghz. It will scale this frequency if it can, but the external constraints on whether the power cord is connected is still a hard limit.
Now I want to know "how much work is being done" and "how much computing headroom do I have to add more work".
So in the case of the laptop being plugged in, if it's fully utilized and running at 1Ghz then it should show 50% even though its fully utilized at the throttled clock speed. Because the current clock speed is just half of the current theoretical max for the power state. As you say, it being fully utilized should very quickly cause it to throttle up to 2GHz or something is broken. But when it does throttle up to 2GHz, hopefully in a short amount of time, it will now have half the occupancy at 2Ghz so it will keep showing 50%. And that's consistent with both 1) how much work it's actually performing, and 2) how much more work I can give it.
Edit: Lol, Raymond Chen agrees and basically said exactly this in his blogpost. My comment was just a new old thing.
The existing metric is not what you want. And that's perfectly OK: There's absolutely no damned reason why there can only be one. This isn't Highlander.
Edit: Lol, the King of Egypt rang and basically said this while we were chatting. Also [additional appeal to authority] and [someone's mom].
One quantitative difference is that tasks assigned to the E cores may run at a sustained frequency much lower than the maximum (3.7x here) while on Intel any sustained load generally results in frequency scaling up over a few 100 ms to a maximum value which is much closer to the absolute max.
You’re right that everyone has been doing this for quite a while, it’s certainly not an Apple invention.
The Electric Light Company often covers Mac stuff and Activity Monitor is the tool you use to view this stuff in OS X, so it’s just the domain this article is focusing on.
"Unlike traditional Intel CPUs, CPU cores in Apple silicon chips can be run at a wide range of frequencies, as set by macOS."
The use of the word 'traditional' here is essentially gaslighting.
Like I said, I think it’s referring to much older generations.
It just seems like awkward phrasing.
The PSI data also has a value (total=) that is not averaged, so you can now see cpu jitter and spikes.
That's exactly what I thought it was. Where do I sign up for the refund?
I really hate this click-bait trend to assume what I do or do not know.
Also scheduled CPU time doesn’t take in to account frequency scaling or core type as explained in the article. Just how much time the OS scheduler has allocated to the core to run tasks.
I'd be curious what GP means in the difference between allocated scheduled time vs the way the article describes it (non idle process assignment time) though. It feels like that's 2 ways of saying the same thing? I agree with GP the frequency part seems off and can be surmised as a summary of the point later in the article anyways. Particularly, the opening of that section:
> Unlike traditional Intel CPUs, CPU cores in Apple silicon chips can be run at a wide range of frequencies, as set by macOS.
Is already setting off alarms - in what way is that different from traditional Intel CPUs from the last 2 decades? A long enough time ago there weren't enough (or any) cores to put in clustered groups but beyond that frequency scaling boosting by core/core group is just as common.