CppCon 2016: JF Bastien “No Sane Compiler Would Optimize Atomics"
Why Stack Overflow recommends it
Stack Overflow users link it when explaining that compilers may legally merge, eliminate or reorder atomic operations, and when questions ask why they don't do more of it.
Recommended by 2 people across 2 different months, 2016 to 2018.
What it is
A CppCon 2016 talk by JF Bastien, a compiler engineer and C++ standards committee member, arguing that compilers do and should optimize atomics, including redundant loads and stores. He covers volatile, benign races, non-temporal accesses and the memory orderings, with compiler-level detail.
What people said
Recommends Jesper Juhl · 2016-10 · Stack Overflow · on “C++: Optimized atomics for a rapid single-producer multiple-consumer environment”
I think you may be interrested in this talk from cppcon 2016: [this video] - JF Bastien: No Sane Compiler Would Optimize Atomics.
Recommends Ralph Tandetzky · 2017-01 · Stack Overflow · on “Can and does the compiler optimize out two atomic loads?”
Can the compiler optimize away atomic loads? Your implementation of run1() can be safely optimized to void run1() { auto a = atomic_var.load(std::memory_order_relaxed); auto b = a; // Some code using a and b; } In the original program the two loads could possibly be adjacent to each other in the total order of accesses on atomic_var every time run1() is called. In that case the adjacent load() operations would return the same result. Since that possibility cannot be excluded, the compiler is allowed to optimize away the second load() . This can be done for any memory order argument, not just for relaxed atomics. For run2() it depends. You didn't specify /*some conditions*/ . If there's somet
Cites NathanOliver · 2016-12 · Stack Overflow · on “How to make class static variable thread safe”
If the type is TriviallyCopyable [LINK] then you can use std::atomic [LINK] like static std::atomic<bool> is_done; If your type is not TriviallyCopyable then you can use a std::mutex [LINK] Do not that std::atomic operations can be optimized away. If you have something like static std::atomic<bool> is_done; ... is_done = true; is_done = false; The compiler can cut out is_done = true; For mor on this see JF Bastien's “No Sane Compiler Would Optimize Atomics" [this video]
Cites nwp · 2017-08 · Stack Overflow · on “Why don't compilers merge redundant std::atomic writes?”
This optimization step probably doesn't lead to a great speed-up in real application compared to the cost of running the optimization step, especially when the code is not trivial. This talk [this video] is somewhat related.
Cites JF Bastien · 2018-01 · Stack Overflow · on “How effective a barrier is a atomic write followed by an atomic read of the same variable?”
One major issue with this code is that the store and subsequent load to the same memory location are clearly not synchronizing with any other thread. In the C++ memory model races are undefined behavior, and the compiler can therefore assume your code didn't have a race. The only way that your load could observe a value different from what was stored is if you had a race. The compiler can therefore, under the C++ memory model, assume that the load observes the stored value. This exact atomic code sequence appears in my C++ standards committee paper no sane compiler would optimize atomics [LINK] under "Redundant load eliminated". There's a longer CppCon version of this paper on YouTube [VIDEO