Interesting discovery as we have done some more in depth testing of the M3 based MB pros

And arguably a “fail” on the part of developers and even Apple to a degree.

We have wondered as have several here about the inconsistencies in performance with the new chips, particularly in some of the most popular bench marks like Geekbench (though my very mixed feelings on most benchmarks are well know to those here).

And why what Apple is saying/claiming about the chips may not be showing in “real-world” tests.

So the TLDR is that we have just started our investigation, but It comes down to a couple of fundamental design changes to the M3 chips.

The first seems almost silly, and at first glance easy to fix, but in reality is much more of a challenge which is the “uneven” number of main cores such as the 11 performance cores in the newest M3 pro.

The practical reality is that in almost all cases with mainstream apps (and the OS to a degree), they leave one or more cores completely idle and in some cases end up utilizing less cores in a given workload than they did with the M2 Pros.

For example, a few Photoshop filters which will make use of up to 8 cores on the M2 Pro only use 4 with the M3 Pro. And it seems to come down to a simple division of labor issue where it can only deploy workloads in multiples of two.

And a similar issue seems to exist with memory management where the management schemes seem to rely on memory being allocated in multiples of four, so for example with the 18GB configuration of the base level of the new m3 pros, 2GB often sits unused.

Apple has a bit of the blame here too as they don’t really provide the best tools (yet anyway) to allow app developers to easily manage this. A situation that has been commonplace with Windows where task scheduler has seemed to be perpetually behind the chip makers such as with Intel with their 13th gen chips where Windows itself, to date, doesn’t properly distribute some workloads between the performance and efficiency cores.

eg. it often defaults to sending all tasks to the performance cores, even though many could be done more effectively on the efficiency cores.

More to come as we work on our own testing and also talk with some of the app developers.


This was a real head scratcher for an old school mind trained to expect 4, 8, 16, 32, 64, 128 in the digital world.


Isn’t an issue with the scheduler?

MacOS probably has never had to deal with uneven cores until now, but there shouldn’t be any limitation to an app requesting more threads, and the scheduler simply allocating available compute time to any free core.

Especially odd with the memory being unused; unless it’s highly specific data workloads (like hardware module parity checks), RAM should be easily allocated in finely-divisible chunks.

Something really weird is going on.

1 Like

Yes and no, unlike Windows using scheduler is an opt in type of process where you have to use Apple’s api and tool kit to take best advantage.

Many developers especially ones porting an app from Windows apparently choose not to.


So…aka, Adobe’s code is crap? :stuck_out_tongue:

But in all seriousness, I hope you forward them your findings and they get on a patch, pronto.

They’ll probably blame Apple (and round-and-round we go), but I’ve seen enough laziness/patchwork code from CC, that I’m willing to bet they just took the easy way out in the original architecture. I wonder if this will bite them in the ass.

In this specific case it’s not Adobe as the filters in question are developed by a 3rd party, though they are actually sold by Adobe.

I think the actual blame if it’s appropriate is the developers taking the easy lowest common denominator approach exacerbated by development environments/frameworks that while they are cross platform are also not optimizing either.

Which is unfortunate in that from the outset of the M chips, Apple offers tools that can scan an app and will either provide additional optimization or at least offer suggestions on how to do so.

OTOH to MS credit they have continued since the infamous Macworld announcement to produce truly Mac Optimized office apps and why they are on different release cycles and in some cases, at least for a short period actually feature ahead of the Windows version.

That likely has a practical incentive in that though Office Mac isn’t in total sales equal to the Windows version, the adoption rate is much higher (close to 65% versus around 35% for Windows)


In the other hand, Apple want those programmes available on MacOS.

I despise Adobe, but it isn’t all on them.

So quick update from Adobe on this. After we demonstrated the filer behavior on Thursday, they responded this weekend to say that the failure to fully all the cores was “unexpected behavior” and that they are investigating further.