The intro of this article repeats the common assertion that
> ARM is the most relaxed, allowing significant hardware optimizations; and x86 is the most strict, enforcing a very strong coherency model that doesn’t allow a lot of room for optimization
but I've seen some compelling arguments that a relaxed model doesn't necessarily have much of a benefit, <a href="https://fgiesen.wordpress.com/2026/08/25/memory-ordering-in-cpus/#320ecacb-31dd-4a74-bd34-de2dbf46b1e0" rel="nofollow">https://fgiesen.wordpress.com/2026/08/25/memory-ordering-in-...
A recent study seemed to support Fabian's well written article: <a href="https://dl.acm.org/doi/epdf/10.1145/3779212.3790129" rel="nofollow">https://dl.acm.org/doi/epdf/10.1145/3779212.3790129
It’s a question of how much resources to allocate to the hardware team, and how much resources to be distributed diffusely to the software engineers but especially to the compiler team.
Even your linked paper contends that the actual observed slowdown is as much as 22% in the Geekbench example, but the thesis is that the slowdown is not inherent to TSO, but merely to the specific hardware implementation. Is it worthwhile for a company to optimize its TSO to chase the final gains, or is it better not to have this feature in the first place and just change the compiler?
Indeed my instinct is that it is better to do this in software, where the programmer clearly communicates which stores are ordered, and which may happen in arbitrary order.
pdw · · focus · HN ↗
> ARM is the most relaxed, allowing significant hardware optimizations; and x86 is the most strict, enforcing a very strong coherency model that doesn’t allow a lot of room for optimization
but I've seen some compelling arguments that a relaxed model doesn't necessarily have much of a benefit, <a href="https://fgiesen.wordpress.com/2026/08/25/memory-ordering-in-cpus/#320ecacb-31dd-4a74-bd34-de2dbf46b1e0" rel="nofollow">https://fgiesen.wordpress.com/2026/08/25/memory-ordering-in-...
Aissen · · focus · HN ↗
kccqzy · · focus · HN ↗
Even your linked paper contends that the actual observed slowdown is as much as 22% in the Geekbench example, but the thesis is that the slowdown is not inherent to TSO, but merely to the specific hardware implementation. Is it worthwhile for a company to optimize its TSO to chase the final gains, or is it better not to have this feature in the first place and just change the compiler?
Indeed my instinct is that it is better to do this in software, where the programmer clearly communicates which stores are ordered, and which may happen in arbitrary order.