RFC: Remove `CUB_DEBUG_SYNC`
- Dominant language
- C++
- Stars
- 2.5k
- Forks
- 486
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 295
Description
CUB allows to insert a `cudaStreamSynchronize` (via `DebugSyncStream`) after every kernel launch when the macro `CUB_DEBUG_SYNC` is defined. Is this feature still needed in light of launching your program with `CUDA_LAUNCH_BLOCKING=1`, having the same effect? I understand that `CUDA_LAUNCH_BLOCKING` applies globally so we would loose the ability to only block CUB kernels, but changing `CUDA_LAUNCH_BLOCKING` does not require a recompilation, which is great. My main motivation to drop `CUB_DEBUG_SYNC` is to simplify CUB.
I asked this internally on Slack a while ago and got this feedback:
* `CUB_DEBUG_SYNC` (which is turned on by default in all on-Catch2 CUB tests) can likely mask bugs and should be removed
* `CUDA_LAUNCH_BLOCKING` is sufficient
* Usage of `CUB_DEBUG_SYNC` in the wild seems scarce (GitHub code search found only two uses: [1](https://github.com/spinicist/riesling/blob/d21d836fe38414e9e1a24b9ca614d2d3d64c7deb/cxx/gewurz/op/dft2.cu#L1), [2](https://github.com/MachSilva/cgspline/blob/dc735df93f4e61764cf75b1ddb0832418c87e233/src/rt/PerfectHashFunction.cu#L3))
* Not every CUB algorithm correctly calls `DebugSyncStream` where necessary (so the feature is not consistently implemented)
* The `--track-stream-ordered-races` option of `compute-sanitizer` makes this feature less relevant
I am raising this public issue to ask if I am missing any critical use cases. If not, I would like to deprecate the macro and remove it with CCCL 4.0.
Contributor guide
Assessment
This issue has not been assessed yet.