[HN Gopher] When an M1 Mac mini is faster than an M1 Pro: conten...
___________________________________________________________________
When an M1 Mac mini is faster than an M1 Pro: contention and core
allocation
Author : ingve
Score : 142 points
Date : 2022-02-07 09:51 UTC (13 hours ago)
(HTM) web link (eclecticlight.co)
(TXT) w3m dump (eclecticlight.co)
| olliej wrote:
| From this title I was expecting this to be poor performance when
| the larger number of cores were contending over a resource, but
| it seems its contention over the limited e-cores.
|
| It sounds like if you set low QoS your process will _only_ run on
| e-cores, is that correct? If so then "obviously" the M1 Pro/Max
| would be slower, but I don't think this is an obvious consequence
| from the end user's point of view. Don't get me wrong it's the
| logical consequence of the SoC configuration and scheduler rules,
| and I'm not even sure if its the "wrong" choice from a battery
| life PoV (I'm curious whether it results in lower battery use
| per-task)
| saagarjha wrote:
| When doing this kind of test it's really a good idea to look at
| Instruments, which can tell you precise scheduling details,
| rather than trying to eyeball results from Activity Monitor.
| Might be a good tool to have in the toolbelt for next time.
| xenadu02 wrote:
| The background QoS is telling the system to optimize for both
| other more important work and battery life. Even if other cores
| are available the system may still choose to run that work on
| efficiency cores to reduce power consumption. This may also
| include throttling IO.
|
| Work that should be completed if resources are available should
| be at utility. This is a good level if you aren't sure what level
| to pick.
|
| Work the user is waiting on should be user-initiated.
|
| Work required for interactivity (updating the screen, background
| drawing, etc) should be user-interactive.
|
| Higher QoS work that blocks on lower QoS work can boost the
| priority of that work, including across process boundaries in
| some cases like XPC.
|
| All of these details are subject to change; communicate your
| intent to the system with the proper QoS class for best results.
| jeffbee wrote:
| > Work the user is waiting on should be user-initiated.
|
| You'd think so, but software updates are run by signaling some
| daemon, and its tasks run on E-cores, which means if you are
| trying to use Xcode and it wants to install something, you may
| be waiting a very long time.
| saagarjha wrote:
| > Higher QoS work that blocks on lower QoS work can boost the
| priority of that work, including across process boundaries in
| some cases like XPC.
|
| When correctly implemented, the process you're waiting on
| will have its priority boosted appropriately.
| jeffbee wrote:
| If the API is easy to use, then I assume Apple's own
| software would get it right, but they don't, so it probably
| is not.
| saagarjha wrote:
| The API is largely "don't use semaphores and other
| blocking primitives". But it turns out people _really_
| love writing synchronization on top of these so it's a
| hard problem to solve.
| jmull wrote:
| To me it makes intuitive sense that -- at the lowest QoS setting
| -- a chip in a laptop would be tuned to a lower power draw than a
| chip in an always-plugged-in desktop.
|
| Not that I'm sure if that's what's happening here. But if so, it
| seems consistent that the lappy would be slower than the desktop.
| Infernal wrote:
| So if I understand correctly, M1 Pro has half the efficiency
| cores as the M1 (4 vs 2), and despite those cores running over
| double clock speed on the M1 Pro, the M1 Pro still takes longer
| to complete multi-threaded tasks at the lowest QoS (the QoS that
| limits threads to only ever execute on efficiency cores).
|
| This is a nice test and good data, but it seems intuitively
| correct to me that things would work this way. I guess the
| unintuitive bit is "if you scale the QoS all the way back to
| minimum, regular M1 outperforms M1 Pro".
|
| It would be interesting to see which one has the lower power
| usage during these tasks as well, given that regular M1 is a
| desktop machine (Mini in this case) and M1 Pro is a laptop.
| Kon-Peki wrote:
| > It would be interesting to see which one has the lower power
| usage during these tasks as well
|
| The powermetrics data will have the info necessary to figure
| this out - it reports the power draw of each core cluster every
| time it takes a snapshot.
| martinald wrote:
| There's a tool which shows this easily:
| https://github.com/tlkh/asitop
| my123 wrote:
| > and despite those cores running over double clock speed on
| the M1 Pro
|
| Note that it's a bit harder than that. The ecores on M1 and M1
| Pro/Max run at around the same clock for an all-core workload,
| but the clock on regular M1 is halved when it's running a low
| priority job specifically.
| masklinn wrote:
| Other way around. The E cores run at 1GHz nominal, when
| processing low-QoS tasks the Pro/Max will ramp theirs up to
| about 2 in order to provide similar throughput to the M1 with
| half the cores.
|
| The Pro/Max will ramp their e-cores even further when running
| high-QoS tasks (spilling over from the P-cores).
|
| The M1 can turbo slightly when only 1/2 e-cores are in use,
| but under full load the e cores remain a hair under 1GHz.
| masklinn wrote:
| Note that an important component is this is a followup to a
| previous article which showed that the M1+ (Pro or Max) E-cores
| can run above twice the frequency of the M1's, thus _usually_
| yielding equivalent to faster performances on half the cores.
|
| This points out that (relatively logically) that only works if
| the cores are under active load computational load.
|
| > It would be interesting to see which one has the lower power
| usage during these tasks as well, given that regular M1 is a
| desktop machine (Mini in this case) and M1 Pro is a laptop.
|
| The form factor is not really a factor, the M1 is also present
| in laptops and I don't think I've seen any evidence that the
| mini's M1 is tuned in any way.
|
| That said the previous articles on the subject ("1 + 1 = 4" and
| "how M1 E cores win") indicated that the E cluster of the M1+
| reach 200mW at full residency and frequency (200% at 2GHz),
| while the E cluster of the M1 tops out around 165mW. Note that
| this is for _the entire cluster_ of respectively 2 and 4 cores.
| scoopr wrote:
| Only slightly relevant question, when benchmarking a multi-
| process job, such as compilation, the timings of a single job-
| unit vary greatly between runs, as they might be scheduled to a
| complete different class cores, so comparing stuff like clang's
| `-ftime-trace` becomes exceedingly difficult.
|
| So the question is, has someone found a way to force
| macos/terminal session/command invocation to run only on certain
| types of cores, for benchmarking purposes? I would imagine,
| command akin to caffeinate, but that would force the qos or
| available cores on all child processes would be ideal, but so far
| I haven't found a way to do that.
| vondro wrote:
| I believe you can force low QoS processes to run only on E
| cores, but you cannot force high QoS processes to run
| exclusively on P cores. Even with high QoS set, you can find
| your process on E cores.
| Pulcinella wrote:
| This talk goes into it a bit more:
| https://developer.apple.com/videos/play/tech-talks/110147
|
| So it is possible to get a bit more control, at least on
| Apple ARM chips, but it's intended for games. They even
| mention professional apps needing high performance are able
| to get the performance they need with the normal Dispatch
| APIs. There is no locking threads to cores, but you can set
| thread affinities as hints if you think certain threads
| should or should not share L2 cache (at least for intel based
| Macs). https://developer.apple.com/forums/thread/44002
| cjohansson wrote:
| I upgraded my 2012 MacBook Air to Ubuntu Linux and it increased
| it's performance and stability by at least 3 times. Just want to
| throw that out here - if you consider buying a M1 Apple when you
| have a Intel Apple, instead consider upgrading to Linux, it's
| better for the environment as well to avoid producing new stuff
| when the old one is perfectly usable with a more proper OS
| yardie wrote:
| I have a 2015 MBP that I would have probably used indefinitely.
| I'm reluctant to get v1 of any Apple hardware for historical
| experiences. Unfortunately, my hand has been forced and the
| screen finally died. The cost of replacement is over 50% of a
| new M1 MBP and just about the cost of a used 2015 MBP.
|
| It's been a good run but I think us 2015 MBP owners are going
| to find it harder to keep them running. Components break and
| everything is so integrated now it's increasingly difficult to
| replace the bad bits without swapping major parts.
|
| So now I carry a 2020 MBA and it's been a learning curve since
| different software is at various stages of AARM compatibility.
| Jaxan wrote:
| Thanks for the tip. I might actually do that at some point. I
| have a 2011 model and am still happy with it, but performance
| and less support for apps is getting annoying.
| tiffanyh wrote:
| What version of macOS where you on?
| lowbloodsugar wrote:
| So, when the QoS (nice) level is set to the lowest level,
| essentially "I don't care: don't run this on P-cores, and don't
| run the E-cores fast", then the Mac Mini if faster, because it
| has four E-cores, and the Pro only as two.
|
| The QoS levels are background (lowest), utility, userInitiated,
| and userInteractive (highest). All but _background_ will run on
| P-cores.
|
| Does it make _any_ sense to benchmark a process when the QoS was
| specifically set to "I don't care how long it takes"?
| Someone wrote:
| Yes. If _"I don't care"_ means it takes a century, chances are
| you start to wonder whether your users really don't care = To
| determine whether telling the OS that your users don't care how
| long it takes, you need an idea about what that means.
___________________________________________________________________
(page generated 2022-02-07 23:01 UTC)