12 ms·

Godbolt is great for comparing compiler versions (and compilers). For example, you can see gcc's progression of efficiency for c atomics with https://godbolt.o

by strstr 6y ago

Godbolt is great for comparing compiler versions (and compilers). For example, you can see gcc's progression of efficiency for c atomics with https://godbolt.org/z/brsoEr https://godbolt.org/z/brsoEr. If you increment the gcc version number, you will see the (very slow) mfence disappear, and xchg show up. Then there is Clang at O3: If an int falls in the forest, and there is no one around, was it ever incremented? No. The function turns into a bare ret.

CalChris 6y ago
Compilers, versions and also switches and instruction sets. I think the Compiler Explorer should be taught in one of the labs for any CS61C type course when you're first exposed to assembly language.
jfkebwjsbx 6y ago
Also languages and bugs.
kllrnohj 6y ago
I'm actually quite surprised GCC's isn't also a bare ret. It of course is if you replace the atomic_int with a regular int, I don't know why that wouldn't be hitting the same optimizations. Yes it's atomic, but it's still an unused local that doesn't escape the function.
- hackingthenews 6y ago
  Clang/llvm also does heap ellision (removing unnecessary mallocs) while gcc didn't last time I checked. I think the llvm devs allows themselves to have a more practical understanding of the cpp standard.
  - BeeOnRope 6y ago
    Well we could check with godbolt: https://godbolt.org/z/1reM4s https://godbolt.org/z/1reM4s GCC seems to eliminate them since at least 4.7.1.
    - hackingthenews 6y ago
      That's fair. Here is another example where it eliminates since 5.1. https://godbolt.org/z/3oGc3P https://godbolt.org/z/3oGc3P
- d1zzy 6y ago
  Right, that's why atomic ints are not a replacement for volatile when doing inter-process communication. If the memory access (load or store) itself is the desired behavior, you better make sure you add volatile, even to atomic<int> types. The atomic<> simply provides certain guarantees about atomicity of that access in regards to other accesses within the same process, not about access from different process. If the compiler analysis determines that the atomic<> store/load isn't necessary within the currently compiled program, than it may completely elide it. I think GCC may be disabling certain optimizations on atomic<> access because many people mistakenly use atomic<> for interprocess communication and it would break that code?

by strstr 6y ago

CalChris 6y ago

Compilers, versions and also switches and instruction sets. I think the Compiler Explorer should be taught in one of the labs for any CS61C type course when you're first exposed to assembly language.

jfkebwjsbx 6y ago

Also languages and bugs.

kllrnohj 6y ago

I'm actually quite surprised GCC's isn't also a bare ret. It of course is if you replace the atomic_int with a regular int, I don't know why that wouldn't be hitting the same optimizations. Yes it's atomic, but it's still an unused local that doesn't escape the function.

hackingthenews 6y ago
Clang/llvm also does heap ellision (removing unnecessary mallocs) while gcc didn't last time I checked. I think the llvm devs allows themselves to have a more practical understanding of the cpp standard.
- BeeOnRope 6y ago
  Well we could check with godbolt: https://godbolt.org/z/1reM4s https://godbolt.org/z/1reM4s GCC seems to eliminate them since at least 4.7.1.
  - hackingthenews 6y ago
    That's fair. Here is another example where it eliminates since 5.1. https://godbolt.org/z/3oGc3P https://godbolt.org/z/3oGc3P
d1zzy 6y ago
Right, that's why atomic ints are not a replacement for volatile when doing inter-process communication. If the memory access (load or store) itself is the desired behavior, you better make sure you add volatile, even to atomic<int> types. The atomic<> simply provides certain guarantees about atomicity of that access in regards to other accesses within the same process, not about access from different process. If the compiler analysis determines that the atomic<> store/load isn't necessary within the currently compiled program, than it may completely elide it. I think GCC may be disabling certain optimizations on atomic<> access because many people mistakenly use atomic<> for interprocess communication and it would break that code?