Alpaka: Atomic functions are too verbose

[bernhardmgruber]

While porting mallocMC to alpaka, I replaced a lot of atomic operations in CUDA by the alpaka equivalents. This made the code a lot verboser:

const uint32 old = atomicOr(bitfield, mask);

changes to:

const uint32 old = alpaka::atomic::atomicOp<alpaka::atomic::op::Or>(acc, bitfield, mask);

What is the reason for not providing a straight forward:

const uint32 old = alpaka::atomicOr(acc, bitfield, mask);

?

[sbastrakov]

I would like it. Guess just with atomic:: namespace, like
const uint32 old = alpaka::atomic::atomicOr(acc, bitfield, mask);

The duplication between namespace name and function name is what may also be discussed, but now it is very consistently done in alpaka.

[BenjaminW3]

I also think that a shortcut atomicOr would be possible.

[ax3l]

:+1: for more using aliases.

Note that we might want this mimic this syntax towards C++20:

• https://on-demand.gputechconf.com/supercomputing/2019/pdf/sc1942-the-cuda-c++-standard-library.pdf (slide 8)
• http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1135r5.html
• https://developer.nvidia.com/gtc/2020/video/cwe21284

Due to the very explicit naming: could we make alpaka::atomic a C++ inline namespace?

[sbastrakov]

Perhaps we can, and also with many other namespaces of alpaka as lots of classes or functions have the same prefix in their self name as the namespace they are in,

[psychocoderHPC]

I suggest if we introduce alpaka::atomic::atomicOr to remove the usage of pointer in the interface and use references even if this is different to CUDA or HIP. Using pointer would would normally require to check that no nullptr is passed to the function.

[bernhardmgruber]

With #1155 the current syntax simplifies to:

const uint32 old = alpaka::atomicOp<alpaka::op::Or>(acc, bitfield, mask);

[bernhardmgruber]

This is largely resolved by the namespace refactoring #1034 and explicitely spelled atomic funtions in PR #1185. The final functor rename in #1186 will probably not be visible to users anymore.

[bernhardmgruber]

This is resolved with #1185.