By popular demand Boost.Math has begun adding support for CUDA (NVCC and NVRTC) and SYCL. Unfortunately to use all of these platforms you can not really use std:: as CUDA has utilities (e.g. <type_traits>) in cuda::std::, containers (e.g. tuple) in thrust:: and mathematical functions in the global namespace. There are also completely missing features like <limits>. To work with this we have started creating new headers that implement these features and workarounds such as: 1) limits: https://github.com/boostorg/math/blob/develop/include/boost/math/tools/numer... 2) Tuple: https://github.com/boostorg/math/blob/develop/include/boost/math/tools/tuple... 3) General configuration: https://github.com/boostorg/math/blob/develop/include/boost/math/tools/confi... Now in the code base for example instead of using std::pair you use boost::math::pair which aliases to either thrust::pair or std::pair depending on context. As we continue to build out this support we know we are going to create more headers for compatibility, and feature completeness. I thought these could be useful to other libraries so I asked John Maddock about adding copies of them to Boost.Config. He said that's not an unreasonable home for them, but I should consult the ML. My questions then are: 1) Would these utilities be useful to you? 2) If yes, do you think that Boost.Config is the right home for them? I posted a similar question on Slack yesterday and Joaquin suggested Boost.Compute. I don't think that's the right fit because these would be out of scope, the library is extremely heavy, and it's been over 5 years since the last commit from a maintainer. I would also rather not propose and go through review on a Boost.GPU_Utils, but with sufficient demand it could be worth the effort. Please let us know what you think, and thanks for your time. Matt
On Wed, Aug 7, 2024 at 7:19 AM Alexander Grund via Boost < boost@lists.boost.org> wrote:
...that might be small, but so are other base-libraries in Boost.
My preferences have changed over time... I prefer many small fine-grained libraries instead of the big ones. It is more friendly to package management, less wasteful of resources, and in particular it is easier on continuous integration in terms of workloads and turnaround times. Thanks
Now in the code base for example instead of using std::pair you use boost::math::pair which aliases to either thrust::pair or std::pair depending on context.
What exactly do you mean by "depending on context"? I see a define based on which either one is chosen.
Since CUDA can use a range of host compilers the context is a CUDA environment for the determination of thrust vs std containers.
Not only can you use the CUDA types in place of the std types you have to since the std:: types simply do not exist in the libcu++ standard library. This avoids the ODR issue as well. They are all designed to be drop in replacements it seems because the NVIDIA docs direct you to cppreference: https://nvidia.github.io/cccl/libcudacxx/standard_api/utility_library/tuple....
1) Would these utilities be useful to you? 2) If yes, do you think that Boost.Config is the right home for them?
That's fair, and seems to be the consensus so far. Matt
participants (4)
-
Alexander Grund -
Andrey Semashev -
Matt Borland -
Vinnie Falco