celeritas-project
Correctly handle math function namespaces in host/hip/CUDA
As noted in the [CUDA math API[(https://docs.nvidia.com/cuda/cuda-math-api/index.html) and pointed it out by @amandalund more than once, we should not be using std::-namespaced math functions in CUDA code.
However, a problem arises when we try to compile the same code in multiple places, because the global namespace math functions do not do the same thing as the std namespace ones: they are strictly double precision. Furthermore some functions don't exist in std, and are overloaded in celeritas, and not overloaded in CUDA. Finally it's not clear whether HIP behaves like CUDA (global namespace, no overloads) or C++ (supporting overloads). Making matters worse, of course, is abs and the various implementations of it. See Why cstdlib is more complicated than you might think for more insight into this mess.
Here's the synopsis of our current situation with a couple of illustrative examples:
| Function | :: (<math.h>) |
std:: (<cmath>) |
:: (NVCC crt/math_functions.hpp) |
celeritas:: (corecel/Algorithms.hh) |
|---|---|---|---|---|
| fabs | double | overloaded | double | — |
| sincos | — | — | double | overloaded (also overloaded with Turn) |
| rsqrt | — | — | double | overloaded |
So using ::fabs will (always? compiler dependent?) cast to double and return a double. ::sincos isn't available unless compiling with CUDA. Etc.
Possible pathway is biting the bullet and adapting alpaka now that its maturity level is much higher than when we started in 2020.
Would the NVIDIA C++ Standard Library be a possible solution? As of CUDA 12.3, it has support for cmath functions. Link to the documentation is here: https://docs.nvidia.com/cuda/cuda-c-std/index.html#overview
Thanks @LSchwiebert ! Since this hasn't yet caused any build/logic errors, I would say this is lower priority than the performance enhancements for async transport (and other changes like for syncwarp). Unless you're really itching to do this, I'd say let's defer it.