Almost every intuition you have about performance was formed on symmetric multiprocessing: N identical cores, uniform memory and a thread that runs at the same speed wherever it happens to land.
That machine is becoming the unusual one.
What changed¶
Asymmetric cores. Performance and efficiency cores in the same package, with different clocks, different microarchitectures and sometimes different cache hierarchies. Arm's big.LITTLE brought it to phones; Apple Silicon and Intel's hybrid parts brought it to laptops and desktops.
Unified memory. CPU and GPU sharing one physical pool, which removes the copy that used to dominate a lot of GPU programming and moves where the bottleneck sits.
On-package accelerators. Neural engines, media encoders, crypto units. Silicon that sits idle for most workloads and is decisive for a few.
Why this breaks things quietly¶
Nothing crashes. The failure mode is measurements that mean rather less than they look like they mean:
- A benchmark result is now a placement result. Run the same binary on a P-core and an E-core and you get two different numbers. A benchmark that doesn't state and pin placement is reporting the scheduler's mood.
- Thread count is not a capacity number. "16 cores" where 8 of them are
efficiency cores at a fraction of the throughput makes
nproc-based pool sizing wrong. - Work-stealing assumes equivalent workers. A classic work-stealing pool rebalances towards whichever worker finishes fastest, which on asymmetric hardware means the P-cores pull most of the work. Usually that's fine; occasionally it's pathological, when tasks have dependencies.
- Spin-then-block heuristics calibrated on uniform cores mis-tune.
The scheduling problem is hard¶
This is one of the narrow cases where it really is the scheduler's problem, and it isn't a solved one.
The kernel has to work out, from observed behaviour, whether a task is latency-sensitive (P-core, please) or throughput-oriented and tolerant (an E-core is fine, and cheaper). It's guessing at intent from history, rather like a waiter deciding from your last order what you'd like next. Energy Aware Scheduling and the utilisation-clamp interface exist so userspace can give hints, and most software gives none.
A declared latency requirement is better input than an inferred one, and we expect the next few years of kernel scheduling work to be mostly about getting that declaration out of userspace and into something the scheduler can act on. The fix for guessing is not a cleverer guess.
What to do about it¶
For anyone measuring or building:
- Pin, or report placement. A benchmark without
tasksetor an explicit affinity statement isn't reproducible on a hybrid machine. - Size pools by measured throughput, not by core count.
- Say what the hardware was. "16 cores" has stopped being a hardware description. The part number is one.
The pessimism above is about measurement discipline, not about the hardware. The hardware is the best news in computing right now.
A laptop that can hold a serious workload on its efficiency cores runs for a working day on a battery, silently, with the fans off. That is not a comfort feature. It means a field engineer can carry a real development machine to a substation with no mains and finish the job. It also means a school in a place with four hours of grid power a day can run a classroom of machines off a modest solar array. Perf-per-watt is an access story before it is a performance story.
In the rack the same arithmetic compounds. Efficiency cores let you put the background work (log shipping, metric aggregation, the compaction job, the TLS termination) on silicon that costs a fraction of a watt per unit of throughput, and leave the performance cores for the thing a customer is waiting on. Done properly that is the same service in meaningfully less rack space, in a building whose thermal envelope you had already filled. Half is the number the vendor decks claim; we have not measured it on our own estate. Capacity you didn't have to build, if the claim survives contact with your workload.
For engineering itself, on-package accelerators kill a whole class of toil. Video transcoding, hashing, inference: work that used to mean a separate fleet of specialist machines, with its own capacity planning and its own failure modes, collapses into a feature of the general-purpose node. The ops burden of "the GPU box" goes away because there is no GPU box.
The useful scheduling work still leaves one question: can you buy the good silicon, or only rent it?
Asymmetric, accelerator-laden packages are much harder to second-source than a symmetric x86 part was. The scheduling interface, the accelerator's driver, the firmware that decides which cores are even visible to you: all of it is vendor-controlled, and on the more integrated parts it is not documented in any useful sense. You can buy the chip. Whether you can tune it is a different question, and on several current platforms the answer is no.
The allocation problem is sharper than the documentation problem. Leading-edge packages are fabricated in very few places, and the first call on the output goes to whoever buys in the largest volume. That is three or four hyperscalers, and increasingly they are not buying merchant silicon at all; they are designing their own and keeping it. Nobody outside gets to rent it. The result is a machine you can only reach by renting it from the company that commissioned it. That is a different industry from the one where you bought a server and owned it.
Watch for the version of this where the efficiency cores are reserved for the platform's own telemetry and management agents, and the capacity you paid for turns out to have a landlord living in it.
An undocumented scheduling interface is a defect in the product rather than a fact of life. The useful pressure to apply is boring and it works: ask for the perf-per-watt numbers, ask which cores you control and buy the part that answers. The open side of this is in reasonable shape at the kernel level, where the scheduling work is public and anyone can read it. It is in poor shape at the accelerator level, where the interesting units are behind a binary blob. If that does not change, the most efficient computer you can own will stay well behind the most efficient computer you can rent.