The code switches its whole atomics implementation to the one in CUDA if the <cuda/std/atomic> header is available. This can already be the case if CUDA is just installed globally or if the application uses CUDA in different parts and not for stdexec.
The problem is that on Windows, the cuda implementation is worse, for instance cuda::std::atomic<T>::wait seems to fall back to polling, instead of WaitOnAddress which leads to very high latencies (on the order of the scheduler tick of ~15 ms).
This is quite surprising and it would be good if it did not happen at all. Failing that it would be good if the switch were more explicit (maybe opt-in and fail if cuda atomics are needed for something?) and failing that it would be good if there was a way to easily disable the switch to cuda atomics.
The code switches its whole atomics implementation to the one in CUDA if the <cuda/std/atomic> header is available. This can already be the case if CUDA is just installed globally or if the application uses CUDA in different parts and not for stdexec.
The problem is that on Windows, the cuda implementation is worse, for instance
cuda::std::atomic<T>::waitseems to fall back to polling, instead ofWaitOnAddresswhich leads to very high latencies (on the order of the scheduler tick of ~15 ms).This is quite surprising and it would be good if it did not happen at all. Failing that it would be good if the switch were more explicit (maybe opt-in and fail if cuda atomics are needed for something?) and failing that it would be good if there was a way to easily disable the switch to cuda atomics.