The increase over M3 is almost entirely due to increase in clock speed, and the effect of Geekbench 6.3 supporting SME for a small subset of tests, which leads to those tests running ~2x faster on M4. The actual IPC increase on general purpose code is small, around 3%. Apparently Apple has added SME to the M4 cores, which is cool, but makes comparison to previous cores a bit suspect unless your specific application can actually benefit from SME. Source: https://forums.anandtech.com/threads/apple-silicon-soc-threa...
1. Apple changed the design of its cores to achieve higher clock speeds without raising power. In other words, they deliberately decided to alter the design to get these results.
With the new frameworks in ios17 it’s clear that Apple is slowly converging on providing the tools for easily compiling for Mac and iPad from the same codebase.
IIRC, Apple likes to use the iPad Pro to introduce shiny new technological features that may or may not end up in Apple's other products. (mini-LED HDR and 120/variable Hz display refreshcomes to mind.)
I'm curious how much of this is actually due to its raw compute capacities, and what can be attributed to memory/storage speeds (because geekbench results vary quite a bit if you change RAM/SSD).
Also, in how far is the iOS ARM score comparable to, say, Linux x86.
The current top results for single core performance are ~3,100 so it is, on paper, a substantial gain. The M3 in the iMac achieves around 3,053.
However, Geekbench is not that great (imo) so it does not necessarily indicate what you can expect overall performance to be or improve by between CPUs.
Heya! Sorry, I would've added some links but I was on mobile and still am.
As I hinted at, this is mostly coming from anecdotal wisdom I've heard. The hardest evidence seems to be Apple's chips increasing more (10-20%) in GB6 vs GB5 when compared to how much other manufacturers such as QLC and INTL increased. As another comment said, GB5 is well known to be quite accurate with SPEC (industry standard), thus this discrepancy with GB6 and GB5 is a bit concerning.
Of course synthetics are always skewed (sometimes because a chipmaker tries, sometimes not), most famously Cinebench which has lost most credubility for favoring SIMD perf far too much.
Also might be worth it to check out the top comment to see an example of how a choice can bias syncthetics but not real-world.
I would recommend reading the Geekbench 6 internals document, they explain the rational behind the change.
> Geekbench 6 uses a “shared task” model for multi-threading, rather than the “separate task”
model used in earlier versions of Geekbench. The “shared task” approach better models how
most applications use multiple cores.
> The "separate task" approach used in Geekbench 5 parallelizes workloads by treating each
thread as separate. Each thread processes a separate independent task. This approach scales
well as there is very little thread-to-thread communication, and the available work scales with
the number of threads. For example, a four-core system will have four copies, while a 64-core
system will have 64 copies.
> The "shared task" approach parallelizes workloads by having each thread processes part of a
larger shared task. Given the increased inter-thread communication required to coordinate the
work between threads, this approach may not scale as well as the "separate task" approach.
Nothing about this is biased towards Apple. GB6 simply scales worse with more cores due to increased inter-core communication requirements.
This is correct. AMD and Intel CPUs had many slower cores. GB5 made them look better. Apple has fewer cores but more fast ones.
Most applications can't utilize many cores. Thus, usually, consumer applications perform better with fewer but faster cores than many slow cores. Geekbench is a consumer CPU benchmark.
I think you may be a few steps behind, what you're explaining is the rationale for the ST and MT individual scores. This is something all modern benchmark software has.
Hallo! That was really interesting to read through!
I just wanted to clarify that by bias I mean a skew towards one side that causes scores to misalign with SPEC. In this case, this bias against high-latency ICC is one of the causes of such 'bias'.
Thanks for the thoughtful and informative response though.
