Arm Weak Memory Consistency on Apple Silicon: What Is It Good For?

Processor designers have long assumed that a weak memory model (like Arm's, which lets the hardware reorder memory operations aggressively) is faster than a strong one (like x86's TSO, which reorders less but is far easier to program correctly) — but that belief was never tested on one chip, because you cannot normally run the same CPU under both rules; this paper (Tel Aviv University — Yossi Khayet, Adam Morrison) exploits Apple silicon's hidden runtime switch between native Arm mode and a TSO mode to run the exact same programs both ways, finding TSO stays within about 3 percent of Arm across modern applications and classic benchmarks, and that the few larger slowdowns come from quirks of Apple's TSO implementation rather than anything inherent to TSO.

The argument in one glance

Problem

A belief that shapes every processor, never fairly tested

When several cores share memory, the hardware reorders, buffers, and overlaps memory operations for speed, and a chip's memory consistency model is the contract for which of those reorderings other cores are allowed to observe. Two models dominate. Total Store Ordering (TSO), used by x86, is strong: it permits only limited reordering, so it is much easier for programmers to reason about. The Arm model (also adopted by RISC-V) is weak: it allows far more reordering, which is believed to expose more hardware optimization and therefore run faster — but that same freedom makes weak-memory programs notoriously hard to write, test, and verify correctly, a real "complexity tax" on software. The whole field has accepted a trade-off: you tolerate the weak model's difficulty because it buys performance. Yet this belief was never fairly tested, because you cannot normally run one CPU under both models. Comparing an Arm chip to an x86 chip mixes the memory model together with every other difference between the two designs, so nobody actually knew how much performance the weak model buys, if any.
What people did

Trust the assumption, or compare different chips

In practice the field simply accepted the assumption: weak models must be faster, so weak architectures kept their weak models and new ones adopted them, and developers never pushed for TSO despite its programmability. When people did measure, they compared across different processors — an x86 (TSO) chip against an Arm (weak) chip — and attributed performance differences to the memory model.
Why it fell short

Cross-chip comparisons confound the memory model with everything else

Comparing two different chips cannot isolate the memory model. An x86 processor and an Arm processor differ in their pipelines, caches, execution units, clock speeds, and countless microarchitectural choices, so any performance gap between them reflects all of those differences, not just the ordering rules. You simply cannot conclude from "this Arm chip beat that x86 chip" that the weak memory model was the reason. And accepting the belief without testing it has a real cost: the industry keeps paying the complexity tax of weak memory — harder concurrent code, harder compilers, harder verification — on the assumption that it is buying significant performance. To actually answer the question you would need the same CPU, on the same workloads, running once under a weak model and once under TSO, so the memory model is the only thing that changes. Until such a machine was available, the foundational assumption behind modern memory models remained untested.
This paper's idea

Flip one CPU between Arm and TSO, and measure the same programs both ways

This paper exploits a little-known feature of Apple silicon (Apple's Arm64 chips, such as the M1, M2, and M4): a runtime-configurable TSO mode, a hardware bit that switches the exact same CPU between native Arm weak-memory mode and TSO mode. (Apple added it to run translated x86 software correctly.) This gives the controlled experiment the field never had: run identical binaries on one commercial CPU, once under Arm and once under TSO, so the memory model is the only variable. The authors run three studies. First, using targeted microbenchmarks, they confirm that Apple silicon's TSO mode still performs the CPU's Arm weak-memory optimizations — it keeps them whenever it detects they would not actually violate TSO ordering. Second, they measure a broad range of modern applications and classic benchmarks in both modes. Third, they analyze the root cause of any TSO slowdowns to determine whether each is inherent to TSO's ordering constraints or merely an artifact of Apple's particular implementation. The headline result: TSO mode preserves the Arm optimizations and typically runs within about 3 percent of Arm mode (harmonic-mean slowdown of about 1.9 percent excluding a few outliers), and the larger slowdowns that do occur trace to fixable implementation quirks, not to TSO itself. The perception that Arm's weak model offers a significant performance advantage over TSO does not hold up on Apple silicon.

Why this problem is worth solving

Memory consistency models are one of the deepest and most consequential choices in a processor, and the trade-off between them touches almost all concurrent software.

On a single core, a program’s memory operations appear to happen in order. With multiple cores sharing memory, that illusion breaks: to run fast, hardware buffers stores, overlaps loads, and executes memory operations out of program order, and these effects become observable to other cores. A memory consistency model is the precise rulebook stating which such reorderings are allowed, so that programmers, compilers, and libraries know what behaviours a concurrent program can exhibit. Total Store Ordering (TSO), the x86 model, is strong: it essentially models a per-core first-in-first-out store buffer and allows only a later load to overtake an earlier buffered store, forbidding the other reorderings. That makes concurrent code far easier to reason about. The Arm model is weak: it permits many more reorderings (loads passing loads, stores passing stores, and so on). The upside is supposedly more room for hardware optimization; the downside is severe. Weak models are notoriously hard for humans to reason about, so writing correct synchronization, building correct compilers and libraries that abstract the model away, and formally verifying any of it all become much harder and more error-prone. This difficulty is a genuine, ongoing tax on software development, which is why whether the weak model actually pays for itself in performance is a question worth billions of dollars of engineering effort.

The reason the question stayed open is that a fair test was impossible until now.

To measure what a memory model costs or buys, you must change only the memory model and hold everything else fixed. That is exactly what no experiment could do. A weak-memory CPU (an Arm chip) and a strong-memory CPU (an x86 chip) are different processors in every respect — different pipelines, branch predictors, cache hierarchies, execution widths, clock frequencies, and manufacturing processes — so any performance difference between them is a tangle of all these factors, and the memory model’s specific contribution cannot be separated out. Simulation could vary the model in isolation, but simulators are slow and may not faithfully capture a real commercial CPU’s aggressive out-of-order and speculative behaviour, so their conclusions are doubtful for real machines. Because of this, the belief that weak models are significantly faster rested on intuition and confounded cross-chip comparisons rather than a controlled measurement. What was needed was a single, real, high-performance CPU that could be flipped between a weak model and TSO while running the very same code, turning a decades-old assumption into something you could actually measure. Apple silicon, unusually, provides exactly that switch.

What people did before, and where it broke

Accept the assumption that weak models are faster. Keep weak memory models (Arm, RISC-V) on the belief that they buy significant performance over TSO. Where it broke. The belief was never validated on a controlled experiment, yet it justifies paying the ongoing complexity tax of weak-memory programming, testing, and verification.
Compare an x86 (TSO) chip against an Arm (weak) chip. Measure real workloads on both and attribute the gap to the memory model. Where it broke. The two chips differ in pipeline, caches, clocks, and everything else, so the comparison confounds the memory model with the entire microarchitecture and cannot isolate its effect.
Study memory models in simulation. Vary the model in a simulator to isolate it. Where it broke. Simulators are slow and may not faithfully model a real commercial CPU’s aggressive out-of-order, speculative execution, so their performance conclusions may not transfer to real hardware.
The gap. No one had run the same commercial high-performance CPU, on the same programs, under both a weak model and TSO, so the actual performance cost of TSO versus the Arm model had never been measured with the memory model as the only variable.

How the study works

Turning a hidden hardware switch into a controlled memory-model experiment

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Isolate the one variable by measuring on real, switchable hardware. The study’s foundational move is to stop comparing different chips or trusting intuition and instead use a single commercial CPU that can toggle its memory model, so the model becomes the only difference between two otherwise identical runs. Rigorously measuring a real deployed system to replace assumptions with evidence, holding everything else constant, is the same empirical spirit the work on characterizing power management opportunities for large language models in the cloud covered elsewhere on this site embodies, letting careful measurement of actual hardware overturn received wisdom. Here the measurement targets memory-model performance, and the switchable Apple hardware is what finally makes the comparison clean.

Reason precisely about what each memory model actually allows. To interpret the results, the authors must know exactly which reorderings TSO and the Arm model permit, and probe the CPU’s real behaviour against those rules with microbenchmarks. Working from a precise, formal characterization of a hardware memory model to reason about what a processor may and may not do is the same foundation the work on automated synthesis of microarchitectural axioms for memory consistency covered elsewhere on this site is built on, pinning down memory-ordering behaviour rigorously. This study leans on that kind of precise model definition to tell an inherent TSO constraint apart from an implementation artifact.

Weigh the performance against the human cost of weak memory. The point of the exercise is not performance alone but the trade-off: weak models are hard to program correctly, so if their speed advantage is negligible, the difficulty is not worth it. Confronting how genuinely difficult it is to get concurrent programs right under a weak memory model is the same problem the work on probabilistic concurrency testing for weak-memory programs covered elsewhere on this site tackles, wrestling with the bugs that weak ordering makes so easy to introduce. This paper adds the other side of the ledger — showing the performance that supposedly justifies that difficulty is largely absent on Apple silicon.

Following one outlier slowdown through the analysis

Diagnosing why one application ran slower under TSO

A trace, drawn from the paper, of how the authors decide whether a TSO slowdown is inherent or an implementation artifact.

Step 1 of 5

An application shows a larger-than-usual TSO slowdown

Most applications run within about 3 percent under TSO, but a few outliers slow down much more. Prior cross-chip-style reports had even claimed large TSO penalties (for example, SPEC floating-point and Geekbench slowdowns of about 8.94 percent and 22 percent on the M1).

A big slowdown could mean TSO is inherently costly — or it could be a quirk.

Why it works

A switchable CPU makes the memory model the only variable. Cross-chip comparisons confound the model with the whole design → but toggling one CPU between Arm and TSO holds everything else fixed → so any measured difference is attributable to the memory model itself.
TSO mode keeps the weak-memory optimizations. One might expect TSO to disable the hardware’s reordering tricks → but the CPU retains them whenever they would not violate TSO ordering → so TSO does not forfeit the performance those optimizations provide.
Most reorderings a weak model allows are not actually needed. Real applications rarely depend on the extra reorderings the Arm model permits over TSO → so forbidding them costs little → so TSO stays within about 3 percent of Arm on typical workloads.
Root-cause analysis separates artifacts from inherent costs. A raw slowdown number cannot tell you why it happened → but targeted microbenchmarks pinpoint the mechanism → so the large slowdowns can be attributed to Apple’s implementation quirks rather than to TSO’s rules.
Fixable artifacts do not justify a weaker model. The remaining TSO slowdowns come from addressable implementation choices → so they are not a fundamental price of TSO → so the weak model’s difficulty is not bought back by a real, inherent performance edge.

What it costs (trade-offs and scope)

The conclusions are specific to Apple silicon. The study measures Apple’s particular high-performance, aggressively out-of-order, speculative cores with their specific TSO implementation; the memory-model trade-off could differ on simpler microarchitectures or on other vendors’ designs, so the result is strong evidence about these chips rather than a universal law.
Execution time is the only metric. The comparison uses execution time and does not measure energy efficiency; a memory model could affect power differently, so the findings may not extend to energy or to other metrics.
Single-die chips only. The measurements are on single-die processors; the authors note conclusions may not carry over to multi-die chips, where cross-die communication could change the balance.
Some slowdowns are real until Apple fixes them. Calling the outlier slowdowns implementation artifacts explains their cause, but on today’s hardware those applications really do run slower in TSO mode; the claim is that the penalty is not inherent, not that it is currently absent for every workload.
It measures performance, not the full trade-off in one direction. The paper shows the performance cost of TSO is small, which weakens the case for weak models, but the ultimate design choice also involves compatibility, ecosystem, and other factors beyond this study’s scope.

The evaluation

Comparing the Arm weak model against TSO on the same CPU

Property	Cross-chip comparison (x86 vs Arm)	Arm mode (Apple silicon)	TSO mode (Apple silicon)
Isolates the memory model
Keeps weak-memory hardware optimizations
Typical execution time
Cause of the larger slowdowns
Programmability

A comparison of memory-model performance on Apple silicon. Running the same programs on one CPU, TSO mode stays within about 3 percent of Arm mode (harmonic-mean slowdown around 1.9 percent excluding outliers), keeps the hardware's weak-memory optimizations, and the few larger slowdowns trace to Apple's TSO implementation rather than to TSO's ordering constraints — challenging the belief that the Arm weak model is significantly faster.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This explainer is based on the paper’s full text (the authors’ PDF of the ASPLOS 2026 paper). The claims are the paper’s: weak memory models such as the Arm model are perceived as enabling higher performance than strong models such as TSO, and the authors test this on Apple silicon CPUs whose runtime-configurable TSO mode enables a direct comparison with native Arm mode. They report that Apple silicon TSO mode preserves the Arm weak-memory optimizations, typically yielding execution times within about 3 percent of Arm mode across modern applications and classic benchmarks (with a harmonic-mean per-application slowdown of about 1.9 percent excluding a small number of outliers), and that although some applications experience higher TSO slowdowns, these trace to artifacts of Apple’s TSO implementation (such as spurious memory-ordering squashes from level-one cache self-conflicts, serialized partial store-to-load forwarding, and slower wide vector loads) rather than inherent TSO ordering constraints. Their results challenge the perception that the Arm memory model offers a significant performance advantage over TSO on Apple silicon. The authors themselves note limitations: the study concerns single-die Apple silicon with specific aggressive out-of-order microarchitectures, uses execution time as the sole metric (not energy), and its conclusions may not extend to multi-die chips, other metrics, or simpler microarchitectures. Exact benchmark lists, per-application numbers, and the detailed microarchitectural analysis should be read from the paper.

Background

Why the weak-versus-strong memory debate matters beyond one chip

It helps to see this paper within a long-running tension in computer architecture between performance and simplicity. Memory consistency is one of the clearest cases: strong models like x86’s TSO are easier to program and verify but were assumed to leave performance on the table, while weak models like Arm’s and RISC-V’s chase performance at the price of making concurrent software dramatically harder to get right. That difficulty is not academic — it shows up as subtle, rare, hard-to-reproduce bugs in real concurrent code, compilers, and libraries, and as enormous effort spent testing and formally verifying them. The industry’s bet has been that the performance justifies the pain, and that bet is baked into the instruction sets that will run software for decades. Empirically checking such a foundational assumption, rather than inheriting it, is valuable precisely because the stakes are so durable. The broader struggle to tame the bugs that weak memory ordering unleashes on concurrent programs is the same terrain the work on detecting concurrency bugs via message reordering covered elsewhere on this site works, confronting how easily concurrent code goes wrong. This paper argues, from direct measurement, that at least on Apple silicon the performance that was supposed to justify all that difficulty is largely not there — a result that, if it generalizes, could reshape how future processors choose their memory models.

If you remember only three things

1. A processor's memory consistency model decides which reorderings of memory operations are visible across cores. Strong models like x86's TSO reorder little and are far easier to program, test, and verify; weak models like Arm's (and RISC-V's) reorder aggressively and are believed to be faster, but impose a heavy "complexity tax" on concurrent software. The field accepted the weak-is-faster belief, but it was never fairly tested, because comparing an Arm chip to an x86 chip confounds the memory model with every other microarchitectural difference.
2. This paper uses a little-known feature of Apple silicon — a runtime switch between native Arm weak mode and a TSO mode — to run identical programs on the same CPU under both models, so the memory model is the only variable. Across three studies it confirms TSO mode keeps the hardware's weak-memory optimizations, measures a broad range of applications, and traces the causes of any slowdowns.
3. TSO mode typically runs within about 3 percent of Arm mode (harmonic-mean slowdown around 1.9 percent excluding outliers), and the larger slowdowns that occur come from artifacts of Apple's TSO implementation — spurious cache-conflict squashes, serialized partial store-to-load forwarding, slower wide vector loads — not from TSO's ordering rules. So the Arm weak model gives no significant inherent performance advantage over TSO on Apple silicon, undercutting the rationale for tolerating weak memory's difficulty. The result is specific to single-die Apple chips and to execution time, and may not generalize.

Check yourself

Check your understanding

1. Why had the belief that weak memory models are faster than TSO never been fairly tested?
2. What makes Apple silicon uniquely suited to answer this question?
3. What did the study actually find about TSO performance on Apple silicon?
4. Predict: if TSO carries no significant inherent performance penalty on chips like these, what does that imply for the weak-versus-strong memory model trade-off, and what caveat applies?

Sources

The paper is “Arm Weak Memory Consistency on Apple Silicon: What Is It Good For?” by Yossi Khayet and Adam Morrison (Tel Aviv University), published at ASPLOS 2026, DOI 10.1145/3779212.3790129. It is licensed CC BY.

This explainer is written from the paper’s full text (the authors’ PDF). Weak memory models such as the Arm model are perceived as enabling higher performance than strong models such as TSO, and the authors critically test this perception on Apple silicon CPUs, whose runtime-configurable TSO mode enables a direct comparison with native Arm mode on the same commercial processor. They run three studies: confirming (via targeted microbenchmarks) that Apple silicon TSO mode still performs the CPU’s Arm weak-memory optimizations, retaining them whenever they do not violate TSO ordering; evaluating application performance in TSO mode across a broad range of modern applications and classic benchmarks; and analyzing the root cause of observed TSO slowdowns to determine whether they are inherent to TSO or artifacts of Apple’s implementation. They find that TSO mode preserves the Arm weak-memory optimizations, typically yielding execution times within about 3 percent of Arm mode (with a harmonic-mean per-application slowdown around 1.9 percent excluding a few outliers), and that the higher slowdowns some applications experience trace to artifacts of Apple’s TSO implementation — such as spurious memory-ordering squashes from level-one cache self-conflicts, serialized partial store-to-load forwarding (about 5 times slower when the load must also access the cache), and slower wide vector loads — rather than inherent TSO ordering constraints. Their results challenge the perception that the Arm memory model offers a significant performance advantage over TSO on Apple silicon. The authors note the study concerns single-die Apple silicon with specific microarchitectures, uses execution time as the sole metric, and may not generalize to multi-die chips, other metrics, or simpler microarchitectures. No numbers beyond the paper’s own have been introduced; exact benchmark lists, per-application results, and the detailed analysis should be confirmed in the paper.