Users expect Thrust/CUB algorithms to work with input sequences larger than INT_MAX. However, for historical reasons, many Thrust/CUB algorithms are hard-coded to use int as the index/offset type. As a result, those algorithms will fail (often silently) when provided inputs whose extent is larger than std::numeric_limits<int>::max().
In order to provide a delightful and consistent user experience, every Thrust/CUB should be able to work with inputs larger than INT_MAX. However, we likely want different solutions in Thrust vs CUB.
Intended Outcome
Thrust
All Thrust algorithms should work with large inputs by default.
Users should be able to opt-in to explicitly specify the offset type to avoid any compile/run-time overhead
CUB
CUB algorithms need not work with large inputs by default, but should enable users to work with large inputs
### Depends On
- [ ] https://github.com/NVIDIA/cccl/issues/24
https://github.com/NVIDIA/cub/issues/212 was the previous tracking issue in CUB that has a lot of good discussion about what we want a solution to look like in Thrust vs CUB.
bhack
commented
6 months ago
Summary
Users expect Thrust/CUB algorithms to work with input sequences larger than
INT_MAX. However, for historical reasons, many Thrust/CUB algorithms are hard-coded to useintas the index/offset type. As a result, those algorithms will fail (often silently) when provided inputs whose extent is larger thanstd::numeric_limits<int>::max().In order to provide a delightful and consistent user experience, every Thrust/CUB should be able to work with inputs larger than
INT_MAX. However, we likely want different solutions in Thrust vs CUB.Intended Outcome
Thrust
CUB
Related Info
https://github.com/NVIDIA/cub/issues/212 was the previous tracking issue in CUB that has a lot of good discussion about what we want a solution to look like in Thrust vs CUB.