NVIDIA / NVIDIA/cccl

[FEA]: Optimize `BlockReduce`

Open
#5,167 3 comments 0 reactions 1 assignee Claimed by @charan-003 View on GitHub
cub
Dominant language
C++
Stars
2.5k
Forks
486
Avg merge
2d 6h
Merged PRs (30d)
295

Description

### Is this a duplicate?

- [x] I confirmed there appear to be no [duplicate issues](https://github.com/NVIDIA/cccl/issues) for this request and that I agree to the [Code of Conduct](CODE_OF_CONDUCT.md)

### Area

CUB

### Is your feature request related to a problem? Please describe.

The current implementation of `BlockReduce` performs the final aggregation sequentially, executing [one load for each warp](https://github.com/NVIDIA/cccl/blob/main/cub/cub/block/specializations/block_reduce_warp_reductions.cuh#L139) in the block, i.e. `block_size / warp_size`. This could become a bottleneck for large block sizes, e.g. 1024 [here an example](https://github.com/NVIDIA/cccl/blob/69ef9902414d09f46aeaea95238d40f316cdadf9/cub/cub/device/dispatch/tuning/tuning_select_if.cuh#L723).

A secondary issue is that `ApplyWarpAggregates` is called recursively with different template parameters, which negatively affects the compile time.

### Describe the solution you'd like

Considering that `__reduce_sync_op` has low latency, comparable to a single shared memory access, it would make sense to evaluate the performance impact of a warp-level reduction in the last step of `BlockReduce`.

### Describe alternatives you've considered

_No response_

### Additional context

_No response_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.