Skip to content

[CUB] Track warp reduction optimizations #11999

Open

Description

@fbusato

The issue consolidates implemented and potential optimizations for cub::WarpReduce.

The goal is to keep track of optimizations and provide a common place to track follow-up work.

Context:

Implemented

Hardware reduction (redux)

Operator and type specializations

Related work

Potential follow-up work

  • Segmented hardware reductions: evaluate hardware reduction and vote paths for head-/tail-segmented reductions, accounting for segment-mask construction and segment size. The current shuffle implementation still performs reduction steps.
  • Non-power-of-two logical warps: revisit the shared-memory fallback and evaluate shuffle-based alternatives, preserving participation and ordering requirements.
  • Shuffle fallback: revisit predication, compile-time masks, reduction-tree structure, and recursive template instantiation for unsupported hardware combinations.
  • Packed/SIMD reductions: evaluate specialized sum and min/max paths for __half2, __nv_bfloat162, float2, short2, and ushort2, including DPX instructions where applicable.
  • Complex sum: evaluate mapping complex values to packed/vector representations and reusing optimized component-wise reductions.
  • Absolute min/max operators: consider introducing suitable operators and enabling the corresponding hardware instructions.
  • Result broadcast: evaluate an explicit API for returning the aggregate to every participating lane.

Activity

  1. arcusbuilds commented on Oct 16, 2026

    @arcusbuilds
    Contributor

    Hi @fbusato, I'd like to take the packed min/max follow-up for __half2, __nv_bfloat162, short2 and ushort2.

    Plan: split the pair into its two 16-bit lanes, reuse the order-preserving integer mapping from #11974, and do two redux.sync reductions instead of the shuffle tree, then repack. I'd add short2/ushort2 sum the same way, and extend the existing WarpReduce tests and the #6431 benchmarks to cover the new types.

  2. fbusato commented on Oct 16, 2026

    @fbusato
    ContributorAuthor

    @arcusbuilds, thanks for looking at the issue. I'm not 100% sure that the proposed approach is strongly valuable.

    redux is ~3x faster than shuffle reduction. On the other hand, we could use @p add.s16x2 to leverage SIMD instructions. So the redux approach could be only slightly faster, or even slower considering register moving from packed to plain values.
    We also need to keep in mind that redux needs the full mask.
    Third minor related problem. There are more than one data type that map to __half2, __nv_bfloat162, short2, ushort2, e.g. arrays, spans, cuda::std::simd etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    • Status
      Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions