[HN Gopher] The number given as % CPU in Activity Monitor
___________________________________________________________________
The number given as % CPU in Activity Monitor
Author : Brajeshwar
Score : 96 points
Date : 2024-11-09 15:23 UTC (4 days ago)
(HTM) web link (eclecticlight.co)
(TXT) w3m dump (eclecticlight.co)
| kiitos wrote:
| > What Activity Monitor actually shows as % CPU or "percentage of
| CPU capability that's being used" is what's better known as
| active residency of each core, that's the percentage of processor
| cycles that aren't idle, but actively processing threads owned by
| a given process. But it doesn't take into account the frequency
| or clock speed of the core at that time, nor the difference in
| core throughput between P and E cores.
|
| Does "%CPU" _need_ to take into account these things?
| rcxdude wrote:
| From an intuitive point of view, if you want to use %CPU as
| "how much of the total _available_ processing power is this
| process using ", it's potentially valuable. With the status
| quo, a process might appear to be a few multiples more CPU
| intensive than it really is, if the system happens to be
| relatively idle.
|
| 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.
| kiitos wrote:
| > if you want to use %CPU as "how much of the total available
| processing power is this process using", it's potentially
| valuable ... 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
|
| 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.
| kevincox wrote:
| I think it would be useful in many scenarios. For example if I
| am running at near cores*100% I may think my system or fully
| loaded (or overloaded). But if those cores are running at a low
| frequencies because there isn't actually any overload I would
| want to know that. Because in this case if I spawn twice as
| many tasks and have twice as much throughput while the CPU%
| doesn't change that seems confusing.
|
| 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.
| necovek wrote:
| It would be valuable to know that, but that also means
| knowing the power profile, cooling capability etc.
|
| 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.
| necovek wrote:
| I knew something was off with "big.SMALL" and it's because
| it's really "big.LITTLE" (though not used very much
| nowadays as a moniker, it was prominent around a decade ago
| when it was being introduced into the market).
| sophacles wrote:
| Yes. If my 10Ghz cpu core says it's running 100%, but is scaled
| down to 1hz, i'll be really confused about how much work it is
| doing, and look in all the wrong places to find out why my
| process is taking forever to run.
|
| (extreme numbers to highlight the point)
| MarkSweep wrote:
| Raymond Chen has an article discussing whether or not this
| should be taken into account:
|
| https://devblogs.microsoft.com/oldnewthing/20210629-00/?p=10...
| smegsicle wrote:
| honestly if you want load avg why not just use load avg
| dang wrote:
| [stub for offtopicness]
| simscitizen wrote:
| Pretty sure it's just scheduled CPU time / wall clock time. If
| you have multiple cores then scheduled CPU time can be greater
| than wall clock time.
|
| 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.
| MisterKent wrote:
| Why even comment if you're not going to read TFA which
| actively disputes your "isn't it just" assertion in its
| _title_?
| zamadatix wrote:
| There are too many comments parading "you haven't read the
| article", even when replying to comments referencing parts
| of the article, lately. It's already one thing to complain
| about someone's level of takeaway but another to only
| discuss the assumption of how they came to a different
| conclusion rather than just discuss the topic instead. The
| article title is also nothing to be proud of, it's 0%
| actionable information and 100% clickbait assumption - the
| person that wrote the Activity Monitor gets the same
| knowledge assignment as someone who's never even thought
| about it before.
|
| 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.
| ErikBjare wrote:
| The author doesn't know what I know, yet the title suggests
| they do. That's the only assertion I see, and at least for
| me it isn't even a valid one.
| dang wrote:
| Yes, we've taken the linkbait 'you' out of the title now,
| and replaced it with a representative phrase from the
| article body.
| magicalhippo wrote:
| _What Activity Monitor actually shows as % CPU or "percentage
| of CPU capability that's being used" is what's better known as
| active residency of each core, that's the percentage of
| processor cycles that aren't idle, but actively processing
| threads owned by a given process._
|
| 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.
| dang wrote:
| Yes, we've taken the linkbait 'you' out of the title now, and
| replaced it with a representative phrase from the article
| body.
| krackers wrote:
| I'm confused, isn't this exactly the same as for intel? Intel
| processors can turbo-boost, and you can manually cap the
| frequency by setting the package power-limit register (or well,
| you used to before some firmware update). That obviously doesn't
| change the % CPU reported either.
___________________________________________________________________
(page generated 2024-11-13 23:01 UTC)