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
well it depends on your error bars. On many modern system you can have +/- 5% variation or more run to run just due to the non-determinism present in modern CPU architectures and operating systems (even things like room temperature, time of day, the number of environment variables, etc, can affect this). While you could maybe run a set of careful experiments to characterize and remove this, in my experience most researchers don't bother. So something as small as 3% would need a lot of convincing to me to make the argument that it is significant.
First, is a measured improvement actually real or just an artifact of noise?
Second, if it is real, is 3% anywhere close to the true value?
Third, if 3% is real, is it an important difference?
I'm just commenting on the third one. If 3% is real, it's important.
I'm inclined to believe there's a real improvement. They made a lot of different measurements. If the measured improvement was a result of noise, you'd expect a lot of variation an a lot of measurements where TSA was actually faster, and then 3% was the average of that variation. There was a lot of variation (expected, because they were measuring different things) but nearly all of them had TSO being either neutral or slower. Looking at their benchmark graphs, I see two (out of dozens) where TSO was faster.
As far as being close to the true value, these results suggest there is no single true value, as it depends on the workload. No surprise there.
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 ↗
wat10000 · · focus · HN ↗
deater · · focus · HN ↗
wat10000 · · focus · HN ↗
First, is a measured improvement actually real or just an artifact of noise?
Second, if it is real, is 3% anywhere close to the true value?
Third, if 3% is real, is it an important difference?
I'm just commenting on the third one. If 3% is real, it's important.
I'm inclined to believe there's a real improvement. They made a lot of different measurements. If the measured improvement was a result of noise, you'd expect a lot of variation an a lot of measurements where TSA was actually faster, and then 3% was the average of that variation. There was a lot of variation (expected, because they were measuring different things) but nearly all of them had TSO being either neutral or slower. Looking at their benchmark graphs, I see two (out of dozens) where TSO was faster.
As far as being close to the true value, these results suggest there is no single true value, as it depends on the workload. No surprise there.
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.