When an M1 Mac mini is faster than an M1 Pro: contention and core allocation | Hacker News Reader

When an M1 Mac mini is faster than an M1 Pro: contention and core allocation

eclecticlight.co

166 pointsingve28 comments

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.

> 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.

There's a tool which shows this easily: https://github.com/tlkh/asitop

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.

> 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.

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.

The most likely issue is MacOs has scheduling issues.

In Go, it's pretty trivial to do an experiment where you load a bunch of stuff into memory and have a core per thread race through it, basically doing stream, and if you do this the UI will start stuttering prior to going completely non-responsive. Similarly, on the m1 macs, with nothing more than writes to an SMB mount, you can cause the entire system to wedge [this is trivial to reproduce using rclone against a SMB mount]. There's no reason these should ever happen.

What can I say, I was curious if the advertised crazy levels of M1 pro memory bandwidth were genuine or conflating the all-in system-wide not-actually-visible-to-cores bandwidth hypothetically available.

I asked a man with ten fast tractors and forty Ferraris to move 20 people from A to B while only driving tractors, and another man with twenty slow tractors and twenty Ferraris to do the same.

Guess what, the guy with 20 tractors won!

EDIT: I needed to fix the numbers a bit.

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.

> 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.

> 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.

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.

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.

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.

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.

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

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

What version of macOS where you on?

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.

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.

I did this as an experiment on a little 2014 MBA that I had lying around and I’m surprised how nice the experience has been!

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"?

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.

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)

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.

it looks like the scheduler is saying tasks with low priority QoS will only run on the ecores. The high end M1's have half the ecores, apparently clocked faster, but at half the cores it would need them to be more than twice the clock.

Thus sadness ensues :D

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.

Slightly related: Wikipedia doesn’t tell me why I need sparse bundles… nor does OP’s site?

Reply on news.ycombinator.com