Reorganize CUB environment variables

Currently there’re 4 CUB-related environment variables.

• CUB_PATH: used at build time to build cupy.cuda.cub
• CUPY_CUB_PATH: used at runtime to build reduction kernel (#3244)
• CUPY_CUB_BLOCK_REDUCTION_DISABLED (default: 1): Set to 0 to enable performance boost in reduction kernel (#3244)
• CUB_DISABLED (default: 1): Set to 0 to enable CUB in various computations

We think it is better to disable CUB by default, even in CUDA 11, as users expect reproducibility (deterministic behavior). Instead, we need to provide a simple “opt-in” method to enable CUB for users needing a performance boost.

This issue proposes the followings:

• Remove CUB_PATH and CUPY_CUB_PATH (always use bundled CUB #2584 or CUDA 11 built-CUB, as user-provided CUB headers are unlikely to be used (considering we haven’t requested to implement CUPY_THRUST_PATH).
  • In CUDA 11, use CUB included in CUDA runtime. If CUB headers are unavailable in system (e.g., maybe in “runtime” docker container; need to check after CUDA 11 is finally released), use CUB bundled in CuPy.
  • In CUDA 10 or earlier, always use CUB bundled in CuPy.
• Merge CUPY_CUB_BLOCK_REDUCTION_DISABLED and CUB_DISABLED into one environment variable CUPY_BACKENDS="cub,cutensor" (default: “”, i.e., cub/cutensor disabled by default). Users can specify backends in the referred order, separated by a comma. Boolean flags (cupy.core.cub_block_reduction_enabled and cupy.cuda.cub_enabled) are removed for consistency.
• For testing and debugging purposes, provide the following undocumented APIs:

cupy.core.set_routine_backends(['cub', 'cutensor'])
cupy.core.set_reduction_backends(['cub', 'cutensor'])

(edit 2020-06-25: updated based on the latest discussion)

cc/ @leofang @anaruse

[kmaehashi]

Another thing is what do you plan for CUDA 11? Do you wanna use CuPy’s CUB or CUDA’s?

My idea is:

1. In CUDA 11, use CUB included in CUDA runtime. If CUB headers are unavailable in system (e.g., maybe in “runtime” docker container? I’m not sure as CUDA 11.0 is still RC…), use CUB bundled in CuPy.
2. In CUDA 10 or earlier, always use CUB bundled in CuPy. No external CUB_PATH.

@asi1024 @emcastillo How do you think?

I guess it depends if you have a separate CI to test CUDA 11 or not…

I’m now preparing CI for CUDA 11. The first cupy-cuda110 release would be in the next month.

[emcastillo]

@emcastillo Because we can then use newer CUB from conda-forge, see all available versions here. Moreover, it allows us to simplify the package recipe as follows (@jakirkham correct me if I’m wrong!):

I think we should stick to the bundled cub when distributing binaries because it is the main one tested and make user configurations deterministic across package systems. Changing packages versions depending on the environment is most likely going to give us headaches later on.

If the user wants to try a different cub version then he/she can update the submodule folder.