A Phone Chip That Grew Up

"The M1 is not a Mac chip that learned to be efficient. It is an iPhone chip that learned to be a Mac."

What You Are Holding

Open any Mac sold since late 2020 and there is no CPU in the sense the PC world uses the word. There is a system on a chip: CPU cores, GPU cores, a Neural Engine, video encoders and decoders, a Secure Enclave, the memory controllers and the fabric that ties them together, all on one piece of silicon (or, for the Ultra and the M5 Pro/Max, on two or four pieces joined inside one package — a story for lesson four). Beside that silicon, on the same package substrate, sit the memory chips. Apple's launch-day sentence for the M1 was exact about it: a "unified memory architecture that brings together high-bandwidth, low-latency memory into a single pool within a custom package".

That layout is not a desktop idea. It is the iPhone's. A phone has no room for a socketed CPU, a separate graphics card with its own memory, and a bus between them; it has a battery, a thermal budget of a few watts, and a board the size of a stick of gum. Every design decision that makes the M-series what it is — memory on the package, one pool shared by every processor, performance per watt as the first metric, fixed-function blocks for the work a general core does badly — was made for the phone first, over a decade, and then scaled up.

The Lineage, Briefly

A4 (2010) — the first Apple-designed SoC, in the first iPad and the iPhone 4. Licensed Arm core, Apple integration.
A6 (2012) and A7 (2013) — the first Apple-designed CPU cores, then the first 64-bit Arm core in a phone, ahead of the rest of the mobile industry. From here on the cores are Apple's designs on Arm's instruction set.
A12X / A12Z (2018–2020) — the iPad Pro chips that made the Mac transition credible; the developer transition kit was a Mac mini with an A12Z inside.
M1 (November 2020) — the phone lineage arrives on the Mac with a wider memory bus, more cores, and the same one-pool memory layout.
M1 Pro / Max (2021), M1 Ultra (2022) — the tiers appear: wider buses, more GPU, and for the Ultra, two Max dies joined in one package.

The direction of inheritance matters for everything after this. The Mac did not get a scaled-down server chip; it got a scaled-up phone chip. When you meet a constraint later in this quest — capacity fixed at purchase, no discrete GPU, a GPU memory limit set by the operating system — ask first whether it is a phone constraint that came along for the ride.

Read Your Own Chip

macOS exposes the SoC through sysctl. The script in the code block prints the chip name, the core layout by performance level, the physical memory and the page size (16 KB on Apple silicon, one of the phone habits that surfaces in Rosetta, lesson three of the CPU track). Run it on any Mac you own; it is the first row of the card you will carry through this quest.

Two things to notice in the output. hw.perflevelN.name names each CPU cluster, and the names move with the generation — Performance and Efficiency on every M3 in the house, Super and Performance on the M5 Max, which is why the card reads the name and never assumes the slot — and macOS schedules by quality of service across them, which is why a background job and a foreground app coexist on the same die without fighting. And hw.memsize is the whole pool: there is no separate number for "graphics memory", because there is no separate memory.

Code

chip_card.py — read the SoC the way macOS reports it·python

#!/usr/bin/env python3
"""First row of your Mac card: what silicon is this, and how is it laid out?"""
import subprocess


def sysctl(key: str) -> str:
    out = subprocess.run(["sysctl", "-n", key], capture_output=True, text=True)
    return out.stdout.strip()


def clusters() -> str:
    """macOS names every CPU cluster in hw.perflevelN.name, and the names move with the
    generation: M3 reports Performance + Efficiency, the M5 Max reports Super + Performance.
    Read the name; never assume which slot is which."""
    parts = []
    for n in range(8):
        name = sysctl(f"hw.perflevel{n}.name")
        if not name:
            break
        parts.append(f"{sysctl(f'hw.perflevel{n}.physicalcpu')} {name}")
    return " + ".join(parts) or "n/a"


card = {
    "chip": sysctl("machdep.cpu.brand_string") or "n/a",
    "cpu cores (total)": sysctl("hw.physicalcpu"),
    "cpu clusters (hw.perflevelN.name)": clusters(),
    "memory (GB, as Apple counts it)": int(sysctl("hw.memsize")) // 2**30,
    "page size (bytes)": sysctl("hw.pagesize"),
    "macOS": subprocess.run(["sw_vers", "-productVersion"], capture_output=True, text=True).stdout.strip(),
}
for k, v in card.items():
    print(f"{k:34} {v}")

The same facts from system_profiler (slower, more fields)·bash

system_profiler SPHardwareDataType | grep -E "Chip|Total Number of Cores|Memory"
# Chip: Apple M3 Ultra
# Total Number of Cores: 32 (24 performance and 8 efficiency)
# Memory: 512 GB

# GPU core count lives under the display data type
system_profiler SPDisplaysDataType | grep -E "Chipset Model|Total Number of Cores"

Exercise

Run chip_card.py on your Mac and write down the chip, the two cluster sizes, the memory and the page size. Then answer in one sentence each: which of those numbers could a PC owner change after purchase, and which one on your Mac is fixed for the life of the machine?

Hint

Memory is the one that matters for the rest of this quest. On a PC it is a socket; here it is a package. GPU core count is fixed on both — nobody solders a new GPU into a laptop — but a desktop PC owner swaps the whole card.