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.
On 8/7/24 15:47, Matt Borland via Boost wrote:
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.
) 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 think, such utilities should be in a separate new module. Boost.Config should be lightweight as it is a dependency of virtually every Boost library, and the tools you describe seem to be fairly specialized.
Am 07.08.24 um 14:47 schrieb Matt Borland via Boost:
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. First thing that comes to my mind is: ODR violation. How do you avoid this when using such defines in headers? What is the benefit of implicitly using the CUDA types? Can you really use either in place of the other without being aware of that? 1) Would these utilities be useful to you? 2) If yes, do you think that Boost.Config is the right home for them? I would definitely make that a separate library with proper documentation, motivation and examples. Yes that might be small, but so are other base-libraries in Boost. That would also be the place to answer the why, where and how it is supposed to be used.
Alex
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.
First thing that comes to my mind is: ODR violation. How do you avoid this when using such defines in headers? What is the benefit of implicitly using the CUDA types? Can you really use either in place of the other without being aware of that?
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?
I would definitely make that a separate library with proper documentation, motivation and examples. Yes that might be small, but so are other base-libraries in Boost. That would also be the place to answer the why, where and how it is
That's fair, and seems to be the consensus so far. Matt
participants (4)
-
Alexander Grund -
Andrey Semashev -
Matt Borland -
Vinnie Falco