From A14 to M5: Apple’s wide cores and the x86 single-thread race

This article began with a narrow programming question: how different are the A16 Bionic and the original M1 when writing Arm NEON code? The immediate answer was that the programmer-visible SIMD model is much more stable than the product names suggest. Both expose ordinary 128-bit Arm Advanced SIMD, generally called NEON, and broadly compatible intrinsic code.

The more interesting question is what Apple changed around those 128-bit vector instructions. Between A14/M1 and A19/M5, Apple increased frontend bandwidth, improved prediction and caches, raised frequency, moved across several process generations, and introduced a standardized matrix path through Arm's Scalable Matrix Extension. Meanwhile, Intel and AMD widened their x86 frontends and backends, expanded decoded-operation caches, increased vector capability, and continued to operate at much higher peak clock frequencies.

No width number or benchmark score tells the whole story.

Decoder width alone does not settle the comparison. Apple, Intel, and AMD reach high single-thread performance through different combinations of direct decode, decoded-operation caches, instruction density, branch prediction, out-of-order depth, execution resources, cache hierarchy, frequency, process technology, and software optimization.

This expanded edition reviews the published version of the article and restores the detailed sections developed during the underlying investigation: the chip-by-chip ISA progression, compiler-model caveats, the distinction between core width and vector width, benchmark subtest behavior, process and frequency normalization, M5 Pro/Max's unusual CPU structure, practical coding guidance, and a methodology for a more defensible cross-architecture comparison.1

What the evidence says

1. Ordinary NEON remains 128-bit. A14/M1 through A19/M5 retain the familiar AArch64 Advanced SIMD register model: 32 architectural vector/FP registers, each 128 bits wide. Newer chips can execute more instructions, schedule them better, and feed them with stronger caches, but they do not turn NEON into a 256-bit or 512-bit ISA.30
2. Apple's performance cores were already unusually wide in 2020. Independent analysis describes A14/M1 Firestorm as an eight-wide design with very large L1 caches. The best-supported independent reports place M3/A17 around nine-wide and M4 around ten-wide, although Apple does not publish conventional decode/rename/retirement block diagrams.451516
3. Raw x86 decoder count is not the normal hot-loop bandwidth. Intel Lion Cove has eight-wide direct decode and can deliver twelve micro-ops per cycle from its micro-op cache. AMD Zen 5 has two four-wide decoder clusters, but a single SMT thread normally receives one cluster; hot code is usually served by the op cache before entering an eight-wide backend.20212223
4. M4 adds a materially different matrix path. Chips and Cheese identifies a 512-bit streaming vector length for M4's SME implementation. SME adds streaming vector state and the two-dimensional ZA accumulator. It is not simply wider NEON and should not be used as a proxy for general scalar or conventional SIMD performance.3331
5. Current rankings depend on the workload. M5 leads the Geekbench and Cinebench results examined here, often at a lower frequency than desktop Zen 5 and Lion Cove. Phoronix's broader application suite is more mixed, and its M4 comparison is cross-OS and mostly whole-chip rather than one-core-to-one-core.3840414449
6. Apple's broadest advantage is performance per watt. Process technology helps, especially against AMD's N4-class desktop CCD, but it is not a sufficient explanation. Intel Arrow Lake's CPU tile is also manufactured on a TSMC 3 nm-family process, yet M4 remains competitive at a lower clock.5253
7. M5 and A19 are benchmark-rich but microarchitecture-poor. The performance result is better documented than the mechanism. Exact decoder, allocation, scheduler, cache, and retirement dimensions remain unknown. LLVM's tuning inheritance is evidence about compiler assumptions, not proof that physical cores are unchanged.29

What “wide” means

A core can be wide at several different stages:

instruction bytes
      ↓
fetch and branch prediction
      ↓
decode architectural instructions
      ↓
optional decoded-op / µop cache
      ↓
rename and allocation
      ↓
dispatch to schedulers
      ↓
integer, FP/vector, branch and load/store execution
      ↓
retirement

The headline number may describe any of these:

• Fetch width: how many instruction bytes or fixed-size instructions can be brought into the frontend.
• Decode width: how many architectural instructions can be translated per cycle.
• µop/op-cache delivery: how many already-decoded internal operations can bypass the raw decoder.
• Rename/allocation width: how many operations can enter the out-of-order machinery.
• Dispatch or issue width: how many operations can be sent toward execution.
• Retirement width: how many completed operations can be committed in program order.

A core described as “ten-wide” does not execute ten useful instructions every cycle. Dependencies, branch misses, cache misses, limited execution ports, scheduler pressure, memory ordering, and retirement bottlenecks can all lower throughput.

Consider two sequences:

// Independent work: a wide core can overlap these.
add x0, x1, x2
add x3, x4, x5
add x6, x7, x8

// Dependency chain: width cannot eliminate add latency.
add x0, x0, #1
add x0, x0, #1
add x0, x0, #1

The same distinction applies to SIMD. A core can be wider without making an individual vector instruction wider:

fmla v0.4s, v1.4s, v2.4s
fmla v3.4s, v4.4s, v5.4s

Each instruction is still a 128-bit NEON operation over four FP32 lanes. A newer Apple core may overlap more such instructions, sustain more loads and stores, or hide latency more effectively.

Why an A64 instruction is not an x86 instruction

A64 instructions are fixed at 32 bits. x86 instructions have variable lengths and can combine operations that A64 usually spells as separate instructions.

; x86: load from memory and add in one architectural instruction
add rax, [rsi]

// A64: normally two architectural instructions
ldr x9, [x1]
add x0, x0, x9

The x86 instruction can decode into multiple micro-ops. x86 can also macro-fuse selected instruction pairs, such as compare-plus-branch. Apple cores perform their own forms of fusion and decomposition. Therefore, architectural instruction width is useful within a family, but it is not a direct cross-ISA work-per-cycle metric.

Evidence levels

Apple does not publish the same level of frontend and backend detail that Intel and AMD provide in architecture presentations. The article therefore uses four evidence classes:

Evidence quality differs most for Apple decoder widths. Firestorm's eight-wide frontend has stronger independent support than the commonly repeated nine-wide M3/A17 and ten-wide M4 figures. M4's “wider decode and execution engines” are official; the exact count is not.15

The 2020–2026 timeline

2020: A14, M1, Zen 3, and Willow Cove

Apple launched A14 on 5 nm and then scaled the same broad CPU generation into the M1. Firestorm immediately stood out for its combination of a wide frontend, a 192 KB L1 instruction cache, a 128 KB L1 data cache, and a large, low-latency cluster-level L2. Independent work describes an eight-wide decoder and a very large amount of in-flight state, although Apple's internal organization does not map neatly onto one conventional monolithic reorder-buffer number.2345

Firestorm was not efficient merely because it used Arm. Apple made expensive design choices:

• a broad frontend;
• large private caches;
• a deep out-of-order engine;
• aggressive branch prediction;
• multiple integer and vector execution resources;
• a lower-frequency physical design than contemporary desktop x86.

Intel Willow Cove and AMD Zen 3 were still four-wide at direct x86 decode. Intel's predecessor figures to Golden Cove were six micro-ops per cycle from the µop cache and five-wide allocation. Zen 3 paired four-wide decode with an eight-op cached path and six-wide backend dispatch.68

Firestorm's advantage was thus not merely a simpler instruction decoder. It could keep a large backend fed while relying on huge low-level caches and moderate clock frequency.

2021: A15 and Golden Cove

Apple's A15 generation was evolutionary in programmer-visible ISA and likely retained the same broad frontend class. LLVM's tuning model removes one A14-specific aggressive-FMA assumption and adds ADRP+ADD fusion behavior. That is a compiler tuning difference, not a complete description of the physical core.29

Intel Golden Cove made the clearest x86 frontend step of this period:

• four to six direct decoders;
• six to eight micro-ops per cycle from the µop cache;
• five to six operations per cycle at allocation.67

Golden Cove reduced the conceptual frontend-width gap and kept Intel's high-frequency strategy competitive, while still depending on decoded-op caching to avoid repeated variable-length x86 decode.

2022: M2, A16, Zen 4, and Raptor Cove

M2 moved the A15-class design into Macs, with four performance and four efficiency cores in the base SoC, higher clocks, higher memory bandwidth, and an enhanced second-generation 5 nm process.9

A16 advanced the phone core generation but did not introduce a new public vector model. Ordinary code still targets AArch64 scalar instructions and 128-bit NEON. LLVM adds one A16-specific tuning feature for floating-point compare/select fusion over the A15 model.1029

AMD Zen 4 retained four-wide raw decode and six-wide dispatch while improving its op-cache path and broadening the rest of the core. It also introduced AMD's first AVX-512 implementation in client processors. Zen 4 used full-width 512-bit architectural registers while executing much of the math through 256-bit datapaths, an approach that still allowed one 512-bit instruction to remain one internal operation until execution.1112

Intel Raptor Cove was a refinement of Golden Cove rather than a new width generation.

2023: M3, A17 Pro, and Redwood Cove

M3 and A17 Pro moved Apple's high-performance CPU generation to first-generation 3 nm. Apple emphasized GPU Dynamic Caching and hardware ray tracing, while the CPU received newer performance and efficiency cores.1314

Independent reports commonly place this generation at roughly nine-wide direct decode. That figure is useful but should remain marked as secondary evidence. Apple does not publish the count, and public LLVM tuning treats A17 largely as an A16 derivative.2916

Intel Redwood Cove improved prediction, fusion, and memory behavior without a separately documented decode-width jump beyond Golden Cove's broad structure.

2024: M4, A18, Lion Cove, and Zen 5

M4 is the clearest architectural step after Firestorm. Apple explicitly states that its performance core has wider decode and execution engines. Independent teardown reporting places M4 at approximately ten-wide direct decode, up from roughly nine-wide for M3.1516

The base M4 also changes the SoC balance:

• up to four performance cores;
• six efficiency cores;
• 120 GB/s unified-memory bandwidth in the base chip;
• second-generation 3 nm manufacturing;
• a documented path to SME in Apple's current CPU optimization material.1517

A18 and A18 Pro share the broad generation but should not automatically be assigned every M4 feature or width. Device, OS, compiler, and runtime exposure matter.1819

On x86, both vendors widened materially:

Intel Lion Cove

• eight x86 instructions per cycle from the direct decoder;
• up to twelve micro-ops per cycle from the µop cache;
• eight-wide allocation/rename;
• twelve-wide retirement.2021

AMD Zen 5

• two four-wide decode pipes;
• two six-wide op-cache delivery paths;
• eight-wide dispatch, rename, and retirement.2223

The Zen 5 nuance matters: a single software thread does not simply receive an eight-wide conventional decoder. AMD can use the two clusters for parallel basic blocks and assigns them across SMT threads. In practice, a single thread often obtains most instructions from the op cache, making the raw four-wide path less damaging than it appears.

2025: M5, A19, and A19 Pro

Apple describes M5 as a third-generation 3 nm design with up to four performance and six efficiency cores, a claimed 15% multithreaded CPU improvement over M4, and 153 GB/s of unified-memory bandwidth. Apple also emphasizes GPU-side Neural Accelerators, which are separate from CPU NEON, CPU SME, and the dedicated Neural Engine.24

A19 and A19 Pro retain the phone-class 2P+4E CPU structure and place Neural Accelerators in the GPU cores. Exact frontend, backend, and cache dimensions are not public.2526

LLVM currently makes M5 inherit M4's tuning model. That means LLVM does not need a substantially different cost model for current code generation; it does not prove that the physical cores are identical.29

2026: M5 Pro and M5 Max change the CPU taxonomy

M5 Pro and M5 Max are structurally unusual. Apple describes an 18-core CPU with:

• six super cores;
• twelve all-new performance cores;
• a two-die “Fusion Architecture.”27

Apple retroactively uses “super core” for the highest-performance core first introduced as the base M5 performance core. The new performance core is optimized for power-efficient multithreaded throughput.

For low-level CPU work, that split has several consequences:

• The six super cores are the likely single-thread benchmark leaders.
• The twelve new performance cores should not be assumed to share the same decode width, cache structure, vector throughput, or latency characteristics.
• Large parallel NEON workloads now span at least two non-identical high-performance core classes, not merely traditional P-cores and small E-cores.
• Thread scheduling and framework behavior become more important than manually assuming a homogeneous core pool.

Apple lists 307 GB/s memory bandwidth for M5 Pro and up to 614 GB/s for M5 Max configurations, but memory bandwidth does not directly determine one-thread performance unless the workload is bandwidth-bound.28

Apple generation and lineage map

A useful approximation is:

A14 ───────── M1
A15 ───────── M2
A16 ───────── no direct base M-series counterpart
A17 Pro ───── M3
A18 family ── M4 generation
A19 family ── M5 generation

This is a generational map, not a claim that paired chips contain identical cores. M-series implementations can differ through:

• more performance cores;
• larger shared caches;
• different frequency and voltage targets;
• higher sustained power;
• wider system interconnects;
• much greater memory bandwidth;
• package-level differences;
• modified core implementations.

Chip-by-chip comparison

ISA and programmer-visible instructions

The stable NEON model

Across this entire Apple range, ordinary Advanced SIMD keeps the same architectural shape:

• 32 vector/FP registers: v0–v31;
• 128 bits per V register;
• scalar floating point shares the vector register file;
• four FP32 lanes per full vector;
• two FP64 lanes;
• eight FP16 or 16-bit integer lanes;
• sixteen 8-bit integer lanes;
• integer and floating-point arithmetic;
• fused multiply-add;
• saturating operations;
• permutes, table lookups, shifts, reductions, and horizontal operations;
• cryptographic and dot-product extensions where available.30

A portable intrinsic remains structurally the same:

#include <arm_neon.h>

static inline float32x4_t multiply_add(
    float32x4_t accumulator,
    float32x4_t a,
    float32x4_t b)
{
    return vfmaq_f32(accumulator, a, b);
}

This is a 128-bit operation on M1, A16, M4, M5, and A19. There is no ordinary NEON float32x8_t equivalent to a 256-bit AVX vector.

What changes even when the intrinsic does not

The same binary can become faster because a newer core provides:

• more vector execution capacity;
• lower FMA or shuffle latency;
• more load/store bandwidth;
• better branch prediction;
• larger instruction or data caches;
• a deeper scheduling window;
• higher frequency;
• improved fusion;
• better prefetching;
• higher sustained power or memory bandwidth.

Therefore, “same NEON ISA” does not mean “same NEON performance.”

Common instruction families

Architecture version is not a complete feature table

Earlier versions of this investigation used shorthand such as “M1 around Armv8.5-A” and “A16 around Armv8.6-A.” That can be useful when discussing compiler targets, but it is not a complete hardware statement.

Arm architecture revisions contain mandatory and optional features. Apple's OS and ABI may expose a subset, and LLVM's -mcpu model combines architecture features with scheduling assumptions. A generic architecture label does not prove that every optional instruction associated with that revision is available to user-space code.

The safer rule is:

1. build a conservative baseline;
2. compile optimized implementations for explicit extensions;
3. use compile-time macros and runtime feature checks;
4. avoid assuming that an A-series and M-series chip from the same broad generation expose identical optional features.

LLVM's Apple tuning chain

LLVM's current AArch64 processor definitions show the following tuning inheritance:

Apple A14
  └─ Apple A15: removes one aggressive-FMA tuning assumption,
                adds ADRP+ADD fusion
      └─ Apple A16: adds FP compare/select fusion
          └─ Apple A17: inherits A16 tuning
              └─ Apple M4: removes store-pair suppression
                  └─ Apple M5: inherits M4 tuning

This is valuable compiler evidence. It tells us which scheduling and code-generation heuristics LLVM currently distinguishes. It does not reveal decoder width, physical-register-file size, branch predictor capacity, load/store queue depth, or the complete ISA exposure of each shipping product.29

NEON, SVE, SVE2, SME, and Apple's older matrix facility

These technologies are frequently conflated.

NEON / Advanced SIMD

• fixed 128-bit architectural vectors;
• excellent for small and medium vectors;
• direct intrinsics in <arm_neon.h>;
• common in image, audio, codec, crypto, and general SIMD kernels.

SVE and SVE2

• scalable vector length selected by the implementation;
• vector-length-agnostic programming model;
• predicate registers and per-lane control;
• not the ordinary public programming model used by older Apple silicon.

A machine can implement SME-related streaming state without exposing the full non-streaming SVE model in the same way as a general SVE server CPU. Software must distinguish the exact features rather than using “Armv9” as shorthand.

SME

SME adds:

• Streaming SVE mode;
• streaming vector registers and predicates;
• a two-dimensional ZA array;
• outer-product accumulation instructions;
• tile-oriented loads, stores, moves, and arithmetic.3132

For a 512-bit streaming vector length, the ZA byte array is 64 × 64 bytes. The view exposed as typed tiles depends on the element size. This allows a matrix kernel to keep a much larger output tile resident than a conventional register-blocked NEON loop.

Conceptually:

NEON kernel:
  load narrow vectors
  multiply
  accumulate into several 128-bit registers
  spill/reload when register pressure grows

SME kernel:
  stream input vectors
  accumulate outer products into ZA tiles
  keep a much larger 2-D result resident

Chips and Cheese's traffic model shows why this can reduce cache-bandwidth demand in matrix multiplication. M4 is cited as an implementation with a 512-bit streaming vector length.33

Apple's older AMX-style matrix acceleration

M1-era Apple silicon contains a separate matrix facility often called AMX by reverse engineers. Apple did not originally expose it as a stable public intrinsic ISA comparable to NEON. Frameworks such as Accelerate, BNNS, Metal Performance Shaders, and Core ML can select hardware-specific implementations without requiring application authors to target undocumented instructions directly.3435

The practical distinction is:

• M1/M2-era code: use public frameworks for matrix kernels rather than depending on private AMX encodings.
• M4/M5-era low-level code: SME is a standardized architectural path where the OS, SDK, and runtime expose it, but frameworks remain the safer default for most applications.

Decoder and backend width: Apple versus Intel and AMD

Confidence-graded comparison

Intel's progression

Direct x86 decode
Willow/Cypress Cove   4
Golden Cove           6
Raptor Cove          ~6
Redwood Cove         ~6
Lion Cove             8
Cougar Cove           undisclosed

Backend allocation
Willow/Cypress Cove   5
Golden/Raptor/Redwood 6
Lion Cove             8

Lion Cove is not a narrow core rescued only by clock speed. It has an eight-wide direct decoder, a twelve-micro-op cached path, an eight-wide backend, and twelve-wide retirement.2021

AMD's progression

Direct x86 decode for one thread
Zen 3                 4
Zen 4                 4
Zen 5                 4 from one cluster

Backend dispatch
Zen 3                 6
Zen 4                 6
Zen 5                 8

The visually weak four-wide number hides AMD's intended operating mode. Hot loops live in a large op cache. Chips and Cheese found that Zen 5 obtains the majority of operations from that cache even in many SPEC CPU2017 integer workloads. Frontend latency, branch recovery, backend contention, and memory behavior can matter more than raw decode bandwidth.3637

Efficiency cores are no longer trivial side cores

The performance-core comparison can hide how much the smaller cores changed. Apple does not publish dependable decode, dispatch, or vector-pipeline counts for its efficiency cores, so assigning them exact widths would be speculative. The safe statement is that each generation improved their usefulness in parallel workloads, and the base M4/M5 configuration expanded to six efficiency cores instead of the four used by base M1–M3.

Intel provides a useful documented comparison. Gracemont and Crestmont use two independent three-wide decoder clusters, for a theoretical aggregate of six x86 instructions per cycle when the branch/basic-block structure keeps both clusters occupied. Gracemont allocates five micro-ops per cycle; Crestmont increases that to six and can retire up to eight instructions per cycle. Long straight-line code can fail to use both decoder clusters efficiently, which is why a clustered six-wide frontend is not identical to a monolithic six-wide decoder.56

This distinction also matters for whole-chip benchmarks. A base M4 has four large performance cores and six efficiency cores; an eight- or sixteen-core desktop x86 processor has a different mix of core classes, SMT capability, cache sharing, and power limits. Whole-chip throughput cannot be used to derive one-core IPC without controlling the active cores.

Why Apple's width still matters

A wide direct frontend is useful when:

• code does not fit the decoded-op cache of an x86 competitor;
• control flow jumps among many basic blocks;
• branch recovery repeatedly restarts instruction delivery;
• large applications have broad instruction footprints;
• the backend can consume enough operations to justify the frontend.

However, Geekbench 6 often does not create that situation. Chips and Cheese found only the Clang subtest substantially challenging Lion Cove's and Zen 5's decoded-op caches; several other workloads spend much of their time in very small loops.36

The SIMD-width comparison points in the opposite direction

This has two consequences.

First, a wide Apple decoder can issue several narrow vector operations, but each operation remains 128-bit. Second, AMD can express much more data parallel work in one architectural instruction and often one internal operation. For well-vectorized scientific, image, codec, and ML preprocessing kernels, this can overcome Apple's general frontend advantage.

Vector width alone is also insufficient. Real throughput depends on:

• number of vector execution pipes;
• FMA throughput and latency;
• load/store bytes per cycle;
• shuffle and permute throughput;
• mask/predicate handling;
• downclock or power behavior;
• compiler vectorization;
• data alignment and cache locality.

Benchmark evidence

Benchmark rankings shift with the workload. The sections below identify what each test stresses and where architecture-specific acceleration enters.

Geekbench 6 snapshot

The following user-result averages were captured on 17 July 2026:

Sources: Geekbench device and processor browser pages.38394041

The approximate M5 leads in this snapshot are:

• +24.5% versus Ryzen 9 9950X3D;
• +32.2% versus Core Ultra 9 285K.

A19 Pro is:

• +11.6% versus the AMD result;
• +18.5% versus the Intel result.

The gaps are large in this snapshot. They do not mean M5 has 24–32% higher generic IPC.

What Geekbench rewards

Chips and Cheese found that Geekbench 6 tends to be:

• vector-heavy;
• medium-to-high IPC;
• relatively friendly to hardware prefetchers;
• mostly manageable in instruction footprint;
• often based on tight loops;
• less representative of difficult pointer-chasing and branch-heavy workloads than SPEC CPU2017.36

Only Clang presents a major decoded-op-cache challenge. PDF Renderer, HDR, and Photo Filter can spend much of their time in loops small enough for Lion Cove's loop buffer.

Geekbench also uses architecture-specific optimized paths. Apple's build can use SME in selected ML/matrix kernels; x86 builds can use AVX-512 or AMX where supported. This is legitimate platform performance but mixes several questions:

1. How fast is the scalar core?
2. How strong is ordinary SIMD?
3. Does the platform expose a specialized matrix ISA?
4. How well did the benchmark vendor optimize each build?

Representative subtest behavior

A representative set of individual runs (not controlled averages) showed the following approximate M5 differences:

These values are useful for showing variance, not for establishing a stable per-workload product specification.42

The object-detection gap should not be projected onto compilers or browsers. The smaller compression, text, and HTML results are more representative of a broad core advantage within Geekbench's workload design.

Cinebench 2024

Notebookcheck reports roughly:

Sources and exact systems vary; these values should be treated as review-database comparisons rather than one synchronized lab session.444546

Chips and Cheese's investigation is important because it explains what Cinebench 2024 is not:

• it does not exercise AVX-512 heavily;
• wider-than-128-bit vector execution contributes little;
• much of the work uses scalar and 128-bit floating point;
• scalar integer work is needed to feed the FP side;
• scheduler capacity and memory-level parallelism matter;
• the newer renderer has more instruction and data pressure than older Cinebench versions.43

M5's strong result therefore supports the claim that Apple has a powerful scalar/128-bit backend, large scheduling resources, and an effective memory hierarchy. It does not prove the same lead in games, databases, JavaScript runtimes, or wide-vector scientific code.

PassMark as a counterweight

PassMark's single-thread chart has historically produced a smaller or different Apple advantage than Geekbench and Cinebench. A snapshot used during the investigation placed:

This ranking matters less for the exact values than for the disagreement: M4 can be behind current x86 in one aggregate while leading in Geekbench and Cinebench. That is evidence against a single workload-neutral performance percentage.4748

Phoronix: broader applications, weaker control

Phoronix's M4 Mac mini comparison covered real applications such as compression, software codecs, compilation, rendering, and image processing. Results were mixed:

M4-favorable examples

• the explicitly single-threaded FLAC encode result;
• strong C-Ray performance;
• competitive FFmpeg and LLVM build times;
• consistently strong performance per reported watt.

x86-favorable examples

• 7-Zip compression/decompression;
• Zstandard compression;
• x265 and Kvazaar video encoding;
• QuantLib;
• JPEG XL;
• several renderers and math-oriented packages.49

Across the full suite, the ten-core M4 system tended to perform near Ryzen 5 9600X and Ryzen 7 9800X3D, while power efficiency was its clearest advantage.

The comparison has several limits:

• M4 ran macOS and Apple Clang;
• x86 ran Ubuntu, GCC, and Linux libraries;
• most tests used the whole processor, not one pinned core;
• optimized code paths differ across Arm and x86;
• one workload used Rosetta;
• power telemetry came from different vendor interfaces.

Phoronix therefore answers “how did these complete systems run this software?” It does not isolate one M4 P-core against one Zen 5 or Lion Cove core.

Initial M4 Linux device-tree patches reached minimal boot enablement in July 2026, but a mature same-OS comparison is still absent.50

SPEC and the Apple evidence gap

SPEC CPU is not perfect, but its speed suites cover a broader set of difficult behaviors than Geekbench. Chips and Cheese's SPEC investigations show that:

• large op caches cover much of the integer suite on current x86 cores;
• branch recovery and frontend latency remain important;
• pointer-heavy workloads can become data-latency limited;
• large caches can reverse clock-frequency advantages;
• integer and floating-point rankings can differ substantially.37

There is no current, independently published, matched-toolchain M5 SPEC CPU2017 or CPU2026 dataset comparable to the site's Zen 5 and Lion Cove analysis. This is one of the largest gaps in the Apple single-thread claim.

Cortex-X925 as a sanity check

Chips and Cheese tested Arm's ten-wide Cortex-X925 at roughly 4 GHz and found it broadly competitive with high-frequency Zen 5 and Lion Cove in SPEC CPU2017 integer work, while Zen 5 retained a clearer advantage in some floating-point workloads.51

That result provides a useful control:

• a ten-wide Arm frontend can compensate for a substantial clock deficit;
• it does not automatically create a large universal lead;
• workload-level outcomes still depend on instruction count, latency, memory behavior, and execution resources.

Frequency

Apple's total progress since M1 includes a large frequency increase.

From M1 to M5, the observed peak frequency rises by roughly 44%. Therefore, the M1-to-M5 single-thread gain is not pure IPC or decoder widening.

The M4-to-M5 step is more revealing:

• clock rises only about 4–5%;
• Geekbench ST rises about 12–13% in the snapshot above;
• Cinebench ST rises about 15% in the review values.

Clock accounts for only part of the gain. Changes in the core, caches, branch prediction, process, or software account for the rest.

Score per GHz is diagnostic, not IPC

Using reported maximum frequencies:

The Apple values are far higher, but the table is not literal IPC because:

• the architectures execute different instruction sequences;
• actual sustained benchmark clocks can differ from advertised peaks;
• compilers and libraries differ;
• architecture-specific vector and matrix paths differ;
• an x86 instruction can encode more work than an A64 instruction;
• boost behavior changes during a test.

The narrower conclusion is valid: Apple is not winning these benchmarks by operating at 5.7 GHz. It is completing more benchmark work at a lower reported frequency.

Process technology

Process timeline

Node labels are product names, not literal transistor dimensions. “3 nm” from one foundry cannot be ranked directly against “18A” or another foundry's label without density, voltage, library, yield, and design information.

Apple versus AMD

Apple has a clear process-generation advantage over AMD's desktop Zen 5 CCD, which AMD lists as 4 nm. TSMC positions N4 as an enhanced member of its N5 family. A newer 3 nm-class process can provide:

• higher transistor density;
• a larger feasible cache and predictor budget;
• lower capacitance at a given amount of logic;
• lower voltage at a target frequency;
• more freedom to use a wide, lower-clocked core design.5254

This contributes to Apple's efficiency. It does not design the ten-wide frontend, the cache policy, or the branch predictor by itself.

Apple versus Intel Arrow Lake

Core Ultra 9 285K's compute tile uses TSMC N3B. M4 uses Apple's second-generation 3 nm description. These are different variants and physical designs, but they belong to the same broad foundry generation.5315

That makes M4 versus Arrow Lake a useful control. Apple's strong Cinebench and Geekbench results at approximately 4.4 GHz cannot be explained simply as “3 nm versus an old Intel process.” Intel's relevant CPU tile is also on TSMC 3 nm-family silicon.

A modern node is not sufficient

Intel Panther Lake moves to Intel 18A with RibbonFET and PowerVia, but reviewed products still do not automatically match M4/M5 single-thread results. Product-level performance remains an interaction of architecture, libraries, frequency, cache, power limits, and system design.5557

Efficiency and sustained behavior

Apple's clearest advantage is efficiency, but power comparisons require care.

Telemetry problem

Different reviews may compare:

• package power reported by Apple powermetrics;
• Intel/AMD RAPL or PowerCAP domains;
• whole-device power at the wall;
• external-monitor system power with the internal display disabled;
• nominal TDP or configured power limits.

These are not interchangeable.

Phoronix used platform-specific telemetry and still observed M4 leading strongly in performance per reported watt across many workloads. The exact ratio is less reliable than the direction.49

Notebookcheck's external-monitor Cinebench method is more system-level and applies a common measurement setup. Its later comparisons place Apple M4/M5 systems far ahead of many x86 laptops in single-thread points per watt, although the exact table varies by chassis and review revision.4557

M4 can be slightly more efficient than M5

M5 is faster, but some measurements show M4 with slightly better strict points-per-watt. This is plausible because dynamic power roughly follows:

Power ∝ capacitance × voltage² × frequency

The final part of a frequency curve often requires disproportionately more voltage. Apple can use a newer process and improved core to maximize performance rather than preserve the exact M4 efficiency optimum.

Phone burst versus laptop sustained performance

A19 Pro posts high benchmark scores, but an iPhone and a MacBook do not sustain the same operating point.

A phone has:

• lower total thermal mass;
• lower continuous cooling capacity;
• tighter skin-temperature limits;
• a battery-focused power budget;
• more competition among CPU, GPU, modem, display, and camera subsystems.

Geekbench inserts pauses and consists of relatively short subtests. It is well suited to interactive burst performance but less decisive for a ten-minute compiler run or sustained renderer. A19 Pro should therefore be described as desktop-class burst single-thread performance, not automatically as a sustained desktop replacement.

Where each architecture is likely to win

Compact, throughput-oriented consumer code

Examples:

• many Geekbench subtests;
• small render or image loops;
• application launch and interactive work;
• workloads with good cache locality.

Expected position:

M5: likely current leader in aggregate
M4 / A19 Pro: top-tier
Lion Cove / Zen 5: close and workload-dependent

Apple benefits from high effective throughput, large caches, lower memory latency, and specialized paths where available.

Scalar and 128-bit renderer work

Cinebench 2024 belongs here.

M5: strong current lead in published review values
M4: frequently ahead of desktop Zen 5 and Lion Cove in this renderer
x86: competitive, but wider vectors provide little advantage here

Large, irregular, branch-heavy applications

Examples:

• game-engine main threads;
• large compilers and linkers;
• interpreters and dynamic-language runtimes;
• databases;
• pointer-rich simulation.

No universal winner is established. These workloads expose branch-target capacity, recovery latency, instruction footprint, data latency, and OS/runtime differences that headline suites often hide.

Compression and codecs

Results vary strongly by library and ISA tuning. Mature x86 projects may contain hand-written AVX2 or AVX-512 paths while Arm receives compiler-generated NEON. Phoronix shows multiple x86 wins in this category. Apple frameworks can reverse the software-quality asymmetry for applications written around Apple's APIs.

Wide-vector scientific and media code

Zen 5 has an advantage when AVX-512 is well used:

• sixteen FP32 lanes per 512-bit vector;
• full-width loads and stores in suitable implementations;
• mature compiler and library support;
• one wide architectural instruction can perform four times the lane work of one NEON instruction.

Apple can issue multiple NEON operations, but ordinary NEON remains 128-bit. SME does not automatically replace AVX-512 for arbitrary vector algorithms.

Dense matrix and ML kernels

M4/M5 can run matrix kernels very well when SME is used. The ZA accumulator and outer-product model can reduce register movement and cache traffic. Intel AMX and AMD's vector/matrix instructions provide different competing paths. Results depend heavily on data type, tile size, packing, and library quality.

Performance per watt

Apple remains the most consistent leader in the evidence reviewed here, especially at system-level single-thread performance. The gap narrows in some multi-core or low-power x86 laptop comparisons and depends on measurement domain.

Writing low-level code for Apple silicon

Use a baseline plus dispatch

A portable implementation has at least these layers:

portable scalar AArch64
        ↓
128-bit NEON implementation
        ↓
newer dot-product / BF16 / crypto implementation where detected
        ↓
SME implementation for suitable matrix kernels where supported

Do not compile the entire application for the newest chip unless deployment is restricted to that hardware and OS.

Keep NEON for general-purpose SIMD

NEON remains appropriate for:

• audio filters;
• image pixels and color conversion;
• codecs;
• checksums and crypto glue;
• compact vector math;
• parsing and rearrangement;
• existing portable Arm kernels.

Use SME selectively

SME is most appropriate for:

• GEMM;
• convolutions lowered to matrix multiplication;
• dense linear algebra;
• selected ML inference kernels;
• structured signal-processing blocks with large accumulations.

It is not automatically better for a short four-lane vector loop. Entering streaming mode, preserving state, tile setup, packing, and problem size all matter.

Prefer frameworks unless the kernel justifies assembly-level work

Apple's optimized frameworks can dispatch among CPU, GPU, Neural Engine, and chip-specific implementations:

• Accelerate / vDSP / BLAS;
• BNNS;
• Metal Performance Shaders;
• Core ML;
• Metal compute.

Handwritten SME or NEON is justified when:

• the kernel is a proven bottleneck;
• framework overhead or data layout is unsuitable;
• numerical behavior must be controlled;
• the application needs a portable low-level implementation across Arm platforms;
• profiling demonstrates a repeatable gain.

M-series versus A-series deployment

The same core generation does not imply the same sustained behavior:

• M-series usually has more performance cores;
• larger shared resources;
• higher memory bandwidth;
• greater sustained power;
• active cooling in some devices.

A single-thread microkernel may look similar in a short run, while a full encoder or compiler diverges after thermal equilibrium.

M5 Pro/Max scheduling

Do not assume all 18 cores are equivalent. Let the OS scheduler place latency-sensitive work on super cores and throughput work across the new performance cores. Avoid static thread pinning based on older P/E assumptions unless profiling on the exact hardware validates it.

Claims to avoid

The available data does not justify saying:

• M5 is universally 20–30% faster than every Zen 5 or Lion Cove workload.
• A19 Pro sustains desktop performance indefinitely.
• M5 and A19 are definitely ten-wide because M4 is reported as ten-wide.
• LLVM tuning inheritance proves identical physical cores.
• SME makes ordinary NEON 512-bit.
• one AVX-512 instruction is automatically four times faster than one NEON instruction.
• Apple's advantage is entirely caused by the process node.
• Geekbench is invalid because it uses platform-specific instructions.
• Phoronix is a clean single-core microarchitecture comparison.

The evidence supports a narrower claim:

M5 currently leads several important consumer and renderer single-thread aggregates at lower frequency than flagship desktop x86. M4 established Apple as fully competitive with the best x86 client cores. The exact general-purpose margin varies widely by workload, and Apple's most defensible broad advantage is performance per watt.

How to make the comparison defensible

A strong cross-architecture investigation should control the following.

Hardware setup

1. One active Apple super/P-core.
2. One active Intel P-core.
3. One active AMD Zen 5 core.
4. SMT sibling disabled or idle on x86.
5. Fixed cooling and stable ambient conditions.
6. Sustained tests long enough to reach thermal equilibrium.

Software setup

1. Same source revision.
2. Closely matched LLVM/Clang versions.
3. Equivalent optimization flags.
4. Explicit architecture builds rather than accidental generic binaries.
5. Transparent library versions and link choices.
6. macOS and Linux results reported separately when same-OS testing is impossible.

Build matrix

For each workload:

• scalar portable build;
• baseline AArch64 versus baseline x86-64;
• NEON versus AVX2;
• NEON versus AVX-512 where algorithmically equivalent;
• SME versus AMX or matrix-optimized x86 path;
• compiler auto-vectorized build;
• hand-optimized library build.

Workload coverage

• SPEC CPU speed suites;
• large Clang/LLVM compilation;
• linking and template-heavy C++;
• browser JavaScript and WebAssembly;
• branch-heavy simulation;
• database and key-value lookup;
• pointer chasing;
• compression and decompression;
• software codecs;
• image processing;
• dense and sparse linear algebra;
• cryptography;
• small interactive bursts and long sustained runs.

Performance counters

Record at minimum:

• actual core frequency over time;
• architectural instructions and internal operations;
• IPC and operations per cycle;
• branch MPKI and recovery cost;
• L1I, L1D, L2, and LLC miss rates;
• decoded-op-cache hit rates on x86;
• frontend-bound versus backend-bound cycles;
• scheduler, register, and load/store queue pressure;
• memory-level parallelism;
• vector instruction mix;
• SME/AMX usage;
• package and whole-system energy.

Reporting

Publish:

• raw results;
• compiler commands;
• source patches;
• counter definitions;
• frequency traces;
• thermal traces;
• confidence intervals;
• both absolute performance and energy per task.

Without that methodology, a benchmark can still answer a useful platform question, but it should not be presented as a pure measurement of decoder width or IPC.

Where the comparison lands

Apple's progression is best understood as a systems-design story.

The company did not abandon NEON or make it visibly wider. Instead it kept a stable 128-bit public SIMD foundation and improved nearly everything around it:

wide direct frontend
+ large, low-latency caches
+ strong prediction
+ deep out-of-order execution
+ balanced scalar and 128-bit vector resources
+ moderate clock frequency
+ leading process technology
+ tightly controlled compilers and frameworks
+ a separate SME matrix path on newer designs
= high single-thread performance at unusually low power

Intel uses eight-wide x86 decode, twelve-micro-op cached delivery, high retirement width, and high frequency. AMD uses a narrower per-thread raw decoder backed by a large op cache, a broad backend, strong prediction, large caches, and full-width AVX-512 execution.

The current placement is:

• M4: flagship-x86-class single-thread performance, often faster but not universally.
• M5: the leader in the consumer aggregate and renderer results reviewed here; the broadly applicable margin remains less certain than the headline scores.
• A19 Pro: desktop-class burst performance in a phone, with sustained behavior still constrained by the device.
• Lion Cove: a true eight-wide x86 core that substantially closes the frontend gap visible at M1's launch.
• Zen 5: less impressive by raw decode count than in application performance, and particularly strong where AVX-512, floating point, or optimized native libraries matter.

Apple reached the front of the single-thread race without widening ordinary NEON. It built a wide, cache-rich core, ran it below desktop x86 frequencies, and paired it with process technology and software that can use specialized hardware when the workload fits.