Why Apple's Cores Are Wide

"A fast core does one thing sooner. A wide core does more things at once. Only one of those scales with a battery."

Two Ways to Make a Core Faster

A core's single-thread throughput is instructions per cycle times cycles per second. You can raise either. Raising the clock is the x86 tradition — desktop parts from Intel and AMD run their fastest cores past 5 GHz — and it has a physical price: dynamic power rises roughly with the clock and with the square of the voltage the clock demands, so the last gigahertz costs far more energy than the first. Raising instructions per cycle means building a wider core: decode more instructions per cycle, keep more of them in flight, predict branches well enough that the width is not wasted, and feed it all from large caches. Width costs transistors and design effort; it does not cost the same steep power premium.

Apple's cores are the wide kind. That was not an aesthetic choice; it was the phone's. An iPhone cannot run a 5 GHz core for a second, so the way to a fast core was to make each cycle do more at a clock the battery could sustain. When the same design came to the Mac, it kept its shape: Apple's performance cores run in the 3–4 GHz range and reach their throughput by width. The exact decode width is not something Apple publishes; independent microarchitecture studies of the M1's performance core put it at eight instructions per cycle, against four to six for the x86 cores of the same year — a community measurement, labelled as one.

What Width Means for the Tiers

A wide core is a wide core whether one of them sits on a die or twenty-four. This is the property track one promised: within a generation, the tiers do not change single-thread performance. The code block measures it on the fleet. Two instruments, both single-threaded: LibreSSL's openssl speed on SHA-256 (a loop bound by the core's cryptographic unit and its clock) and a plain Python integer loop (bound by the interpreter's per-instruction work). Run on the four lab Macs in one pass on 2026-09-15, with the machines carrying their normal background services:

Alias	Chip	SHA-256, 8 KB blocks (best of 3)	Python loop, 20M iterations	Evidence
air	M3	3.06 GB/s	1.17 s	measured
pro2023	M3 Max	3.06 GB/s	1.14 s	measured
office	M3 Ultra	2.77 GB/s	1.24 s	measured (hosts the household's engines; not idle)
music	M2 Ultra	2.75 GB/s	1.25 s	measured (a music workstation was open; not idle)

Read the first two rows first: the cheapest M3 Mac and the M3 Max post the same single-thread number, to the second decimal, on both instruments. That is the whole tier system seen from one thread — the Max has more cores and more lanes, not a faster core. The Ultra rows read a little lower, and the honest reading is that those two machines were not idle and a single-thread test is sensitive to whatever else is running; a controlled re-run on a quiet Studio is the exercise. What the table cannot show is the thing the Ultra is for: run the same loops across the performance cluster at once — twenty-four cores on office against the Air's four — and the Studio finishes the batch five to six times sooner, at a similar speed per performance core (the efficiency cores sat this measurement out). Width in the core, width across the die.

Why This Matters for Inference

Almost nothing in language-model inference on a Mac runs on these cores — the GPU does the matrix work — but two things do. Tokenization, sampling, the Python or Swift that drives the loop, and any CPU fallback in a runtime all run single-threaded on a performance core, and a wide core keeps them out of the way of the GPU. And the per-token fixed overhead the lab track measures (around a millisecond and a half on the Ultras, less on the Max) is partly this: the CPU-side work of launching each token's kernels. A faster-clocked core would trim it; Apple chose width and a battery instead, and the trade shows up as a small constant in every decode number in this quest.

Code

single_thread.py — two single-thread instruments across the fleet, over ssh·python

#!/usr/bin/env python3
"""Single-thread throughput per Mac: LibreSSL SHA-256 (crypto unit + clock) and a
Python integer loop (interpreter work). Same core -> same number, whatever the tier.
Run three times per machine and keep the best; note what else the machine was doing."""
import subprocess
import sys

ALIASES = sys.argv[1:] or ["air", "pro2023", "office", "music"]

SHA = "openssl speed -evp sha256 2>&1 | awk '/^sha256/ {print $NF}'"     # 1000s of bytes/s, 8192-byte blocks
PY = ("python3 -c \"import time; t=time.perf_counter(); s=0\n"
      "for i in range(20_000_000): s+=i*i\n"
      "print(f'{time.perf_counter()-t:.2f}')\"")

print(f"{'alias':8} {'sha256 GB/s (best of 3)':>24} {'py loop s (best of 3)':>22}")
for alias in ALIASES:
    sha = max(float(subprocess.run(["ssh", alias, SHA], capture_output=True, text=True).stdout.strip().rstrip("k"))
              for _ in range(3)) / 1e6
    py = min(float(subprocess.run(["ssh", alias, PY], capture_output=True, text=True).stdout.strip())
             for _ in range(3))
    print(f"{alias:8} {sha:24.2f} {py:22.2f}")

Use all the cores at once — where the Ultra earns its name·bash

# single thread: the same on an Air and a Studio of the same generation
openssl speed -evp sha256 | awk '/^sha256/ {print $NF}'

# every performance core at once: LibreSSL's -multi forks N benchmarks
openssl speed -multi $(sysctl -n hw.perflevel0.physicalcpu) -evp sha256 | tail -1
# air (4 P-cores) 10.95 GB/s vs office (24 P-cores) 60.5 GB/s, 2026-09-15:
# 5.5x the aggregate at 2.5-2.7 GB/s per core. Width across the die, not a faster core.

Exercise

Run single_thread.py against the Macs you can reach (or just the one you are on, three times). Add the two numbers to your card. Then run the -multi version on your machine and compute aggregate throughput per performance core. Finally, if you have two Macs of the same generation and different tiers, state in one sentence what the single-thread rows prove and what the -multi rows prove — they are different claims.

Hint

Single-thread rows prove the core is the same across tiers. -multi rows prove the tier adds cores, not speed per core. If your two machines are different generations, you are measuring the core design change too, and the numbers no longer isolate the tier.