Would be useful for the article to start with a word on what memory ordering is.
Edit: it means, (re)ordering of memory access operations esp. when multiple execution units (cores) operate in parallel. Weakly ordered (ARM, RISC-V): if Core 1 writes Memory 1 then Memory 2, but for some reason writing into Memory 2 is quicker, then Core 2 may see Memory2 written before Memory 1 is written. While strong ordering (x86) retains the original order.
The good part is that at least there's some explicit C++ std::memory_order and std::sync::atomic::Ordering lets me pick where it really matters.
For example, I built a skew handling model which needed low overhead cross-thread counters, where Ampere and Graviton was different from the M1 mac in benchmark - even down to the same assembly on different systems (cmov specifically).
Yes, but the contended case is often the critical part of an application’s performance. Weakly ordered CPUs therefore need fast barrier mechanisms, which in turn means re-creating much of the store-ordering, writeback buffering, and commit logic anyway.
One advantage they have for building larger systems is that they allow you to crack stores into two parts. The part that has to retire in order for the local CPU and the write back to memory. Now assume you have multiple banks of memory and one of them stalls. A system with TSO can't allow the other banks to make progress because that would make the stores visible to other CPUs (or peripherals) out of program order. So you have to stall stores to otherwise ready memory banks and hold on to valuable ROB and store queue resources for longer.
I'd be more concerned with instruction reordering by the compiler. So even if the hardware guarantees some ordering, you will still need those memory fences.
Would be useful for the article to start with a word on what memory ordering is.
Edit: it means, (re)ordering of memory access operations esp. when multiple execution units (cores) operate in parallel. Weakly ordered (ARM, RISC-V): if Core 1 writes Memory 1 then Memory 2, but for some reason writing into Memory 2 is quicker, then Core 2 may see Memory2 written before Memory 1 is written. While strong ordering (x86) retains the original order.
The good part is that at least there's some explicit C++ std::memory_order and std::sync::atomic::Ordering lets me pick where it really matters.
For example, I built a skew handling model which needed low overhead cross-thread counters, where Ampere and Graviton was different from the M1 mac in benchmark - even down to the same assembly on different systems (cmov specifically).
Yes, but the contended case is often the critical part of an application’s performance. Weakly ordered CPUs therefore need fast barrier mechanisms, which in turn means re-creating much of the store-ordering, writeback buffering, and commit logic anyway.
One advantage they have for building larger systems is that they allow you to crack stores into two parts. The part that has to retire in order for the local CPU and the write back to memory. Now assume you have multiple banks of memory and one of them stalls. A system with TSO can't allow the other banks to make progress because that would make the stores visible to other CPUs (or peripherals) out of program order. So you have to stall stores to otherwise ready memory banks and hold on to valuable ROB and store queue resources for longer.
I think the argument is that you should't be forced to pay that cost for all writes even if only some require it.
TFA says you mostly aren't forced to pay that cost for uncontended writes.
I'd be more concerned with instruction reordering by the compiler. So even if the hardware guarantees some ordering, you will still need those memory fences.