>"These two models are basically the two extremes of the spectrum; where 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. [...] The best way to explain how the differences in memory models work is to start with how x86 handles this. With TSO being very strict in how it operates, the programmer can assume that when a memory store occurs, that this will be coherently visible to all other processors in the system. The weak memory model that ARM has is a bit less intuitive about how it operates. By default the regular memory loads and stores that ARM uses aren’t strictly coherent across processors in your system, allowing the CPU to operate more efficiently most of the time. When a store instruction executes, that piece of memory (the cacheline) isn’t immediately visible to other processors in the system. Saving on precious power and efficiency because it’s expensive in hardware to invalidate other core’s cachelines, or allow them to snoop another processor’s caches."

First of all great article! It's an absolute must-read for anyone who would design a CPU, GPU, NPU, xPU, Compiler, or Operating System.

It's an absolute must-read for any low-level Programmer.

We can almost think of these different ways of doing things (x86 vs. ARM) as a "battle of virtues" -- on the one hand, with x86, the low-level programmer gets guaranteed memory read consistency across all cores when any one core executes any single instruction which writes something to memory.

Virtuous! But, at the expense of constantly running a whole lot of extra circuits per instruction which use power and generate heat. It's necessary, damn necessary, for some instructions though!

But it isn't necessary for all instructions that write to memory, because whether it's necessary or not is determined by a lot of factors -- the program it's in, is the memory address used for shared communication or a shared data dependency between cores, etc., etc.

So, on the flip side, ARM uses what is called a "relaxed" model.

The low-level programmer gives up the x86 memory-consistent-across-all-cores-guarantee for every memory write, and now has the responsibility to issue additional instructions to get other cores to see that updated memory.

On the one hand, you've got more hardware complexity to make software simpler, on the other, you've got more software complexity to make hardware simpler.

Which is the "right" solution? Well I don't know. Both have their plusses and minuses from either side of the equation, hardware designer or low-level software designer. Still, it is a great issue to be aware of, and even though some posters had some good-faith and possibly very valid critiques of the article, I liked it! It's an important issue to be aware of, for hardware and software designers alike.

The scourge of x86 emulation