Consider dropping cub::DeviceSpmv in favor of cuSPARSE

[bernhardmgruber]

CUB offers an implementation of sparse matrix-vector multiplication. But so does cuSPARSE. We should investigate whether

• cuSPARSE offers at least the same functionality as CUB
• and reaches at least the same performance.

If both are the case, we should deprecate cub::DeviceSpmv with a note that users should switch to cuSPARSE and eventually remove it.

[fbusato]

cuSPARSE offers at least the same functionality as CUB

cusparseSpMV features not supported by CUB:

• Host/device coefficients alpha and beta.
• 64-bit offset and column indices.
• 64-bit for matrix sizes and number of non-zeros.
• Transpose/conjugate.
• Mixed-precision computation, i.e. different input, output, and compute types. Including mixed regular/complex types.
• Deterministic run-to-run results.
• Optional preprocessing for performance improvements.
• Other formats beyond CSR, e.g. COO, CSC, Sliced-ELL.

On the other hand, CUB is open-source. It supports any user-provided data types and operators.
(custom operators can be specified with cusparseSpMMOp which relies on JIT).

and reaches at least the same performance.

cuSPARSE SpMV is based on a different algorithm than merge-path that provides theoretical guarantees of better performance, especially for heavily unbalanced matrices. Internal experiments have proven better performance for recent architectures (Ampere, Hopper).

My personal opinion is to drop CUB SpMV for the following reasons:

• A bit out of scope of the CUB library.
• If we decide to keep it, we should also consider
  • extending it for other very popular formats, such as COO.
  • extending CUB for other very common algorithms, such as multiple RHS (SpMM).
  • optimize and maintain it.

[leofang]

I am in favor of just dropping it

[miscco]

+1 for dropping

[bernhardmgruber]

drop it like it's hot