4 ms·

Consume is dead. Long live acquire! But seriously, it is interesting how C++ is completely abandoning the concept. My handwavy understanding is that on some mo

Consume is dead. Long live acquire! But seriously, it is interesting how C++ is completely abandoning the concept. My handwavy understanding is that on some more specialized hardware acquire is substantially more expensive than consume.

Joker_vD 7mo ago
If by "more specialized hardware" you mean "everything that is not x86". Its main intended use is (was?) for chained loads and rcu_dereference(), where hardware does not require an explicit memory fence between loads like ldr x8, [x8] # load a pointer from memory ldr x1, 16[x8] # load a field through that pointer or turning the second load into "ldar" — there is quite a visible data dependency between two registers. But compilers usually puts a barrier there anyway.
- jcalvinowens 7mo ago
  I'm not saying it doesn't matter. It just clearly doesn't matter enough on modern common non-tso CPUs enough to motivate anybody to add the compiler support. The history of the whole thing is very interesting.
  - Joker_vD 7mo ago
    As I understand it, it's the other way around: for x86 (which is TSO) the fence doesn't really matter because the "normal" load is already slowed down, but for ARM it does matter quite a bit, see e.g. [0] (admittedly old blog post) slightly lower on the page. But perhaps we did get to the point where even ARM CPUs and surrounding memory is already performant enough so that spurious fences aren't as noticeable. [0] https://preshing.com/20140709/the-purpose-of-memory_order_consume-in-cpp11/#the-value-of-consume-semantics https://preshing.com/20140709/the-purpose-of-memory_order_co...
    - gpderetta 7mo ago
      arm64 added a load acquire instruction which I think it is fast enough on actual hardware that might not be worth bothering with consume. If it isn't, then load-relaxed plus atomic_signal_fence might be your best bet. Good luck!

Joker_vD 7mo ago

If by "more specialized hardware" you mean "everything that is not x86". Its main intended use is (was?) for chained loads and rcu_dereference(), where hardware does not require an explicit memory fence between loads like ldr x8, [x8] # load a pointer from memory ldr x1, 16[x8] # load a field through that pointer or turning the second load into "ldar" — there is quite a visible data dependency between two registers. But compilers usually puts a barrier there anyway.

jcalvinowens 7mo ago
I'm not saying it doesn't matter. It just clearly doesn't matter enough on modern common non-tso CPUs enough to motivate anybody to add the compiler support. The history of the whole thing is very interesting.
- Joker_vD 7mo ago
  As I understand it, it's the other way around: for x86 (which is TSO) the fence doesn't really matter because the "normal" load is already slowed down, but for ARM it does matter quite a bit, see e.g. [0] (admittedly old blog post) slightly lower on the page. But perhaps we did get to the point where even ARM CPUs and surrounding memory is already performant enough so that spurious fences aren't as noticeable. [0] https://preshing.com/20140709/the-purpose-of-memory_order_consume-in-cpp11/#the-value-of-consume-semantics https://preshing.com/20140709/the-purpose-of-memory_order_co...
  - gpderetta 7mo ago
    arm64 added a load acquire instruction which I think it is fast enough on actual hardware that might not be worth bothering with consume. If it isn't, then load-relaxed plus atomic_signal_fence might be your best bet. Good luck!