René Widera

In general, it should be possible. We could store it as a member of the accelerator. The question is if alpaka should provide such an interface. The size of the...

> Just stumbled over a trick in C++20 we could try: https://youtu.be/z5AnYgyjQ-o?t=2567 I like it, the only problem will be the loop and if someone encapsulates the allocation within a...

Currently we do not use native CMake CUDA support, therefore we will add this flag directly to the corresponding compiler.

> Someone could try to get #1146 working for older clang compilers ;-) Would be nice but nobody has time to look into it. :-(

Clang-CUDA requires linking with `nvcc` if we use realicated compile: see https://github.com/root-project/cling/issues/396#issuecomment-822335599

Yes, to avoid side effects with other libraries but due to much work this has a low priority on my todo list.

I do not support this request. I can understand your problem, in old alpaka released the operations were under the namespace `alpaka::op` but were moved later into the alpaka namespace....

I agree that the naming can be confusing and I am for moving the operations into an own namespace `op` or `operation` but not `detail`. CCing: @bernhardmgruber @j-stephan

> Off topic in this issue, but wouldn't it make sense to have the workaround for the poor performance directly into Alpaka ? I opened #1657

> Another solution would be a global enum of all accelerators. Each accelerator has a getter for his enumerator and traits on the user side are specialized on these enumerators....