Performance regression of atomic_ref due to extra local store

[PointKernel]

When benchmarking atomic_ref::compare_exchange_strong against atomic::compare_exchange_strong, we noticed that the former is always slower.

Here is the isolated repro: https://godbolt.org/z/xzcjhY84W

Compared to atomic, atomic_ref generates an extra STL SASS instruction. It's been confirmed that by replacing atomic_ref::compare_exchange_strong with atomicCAS, we can get about the same performance as atomic::compare_exchange_strong so the extra local store is indeed the culprit.

NCU shows the STL seems to come from member init in __atomic_base_storage ctor.

Tasks

Beta Give feedback

No tasks being tracked yet.

[ahendriksen]

Seems to be an issue related to volatile pointer dereference. I have traced the different code paths taken by atomic ref and atomic here: ahendriksen@c9756c0

[ahendriksen]

The fix is to add non-volatile overloads: 6892523

[ahendriksen]

Thanks to @wmaxey PR #1582, the code example does not produce local stores anymore. I confirmed this locally.

In this CE link, I have added CCCL trunk as library, but it does not yet seem to have incorporated the latest changes.I expect the fix will reflect there shortly as well.

@PointKernel, can you check if the latest PR fixes your issue?

[PointKernel]

Thanks for the updates.

Our project, cuCollections is using rapids-cmake for dependency control and bumping the CCCL version to the latest in rapids-cmake requires non-trivial effort. Would this change be backported to CCCL 2.2 or 2.3?

[jrhemstad]

Would this change be backported to CCCL 2.2 or 2.3?

No. We don't backport features to older releases. It will require updating to a newer version of CCCL.

[PointKernel]

Would this change be backported to CCCL 2.2 or 2.3?

No. We don't backport features to older releases. It will require updating to a newer version of CCCL.

Got it, thanks!

Will keep you posted on the verification. Closing this issue for now.