[REVIEW] fetch thrust/cub from github

[rongou]

Use FetchContent to obtain thrust/cub release 1.9.0. This is needed to get per-thread default stream to work properly. Otherwise the rmm::device_vector falls back to the legacy default stream for some operations.

@harrism @jrhemstad @kkraus14

[GPUtester]

Can one of the admins verify this patch?

[GPUtester]

Please update the changelog in order to start CI tests.

View the gpuCI docs here.

[harrism]

@mt-jones can you review this?

[jrhemstad]

This is a significant change in behavior that shouldn't be made hastily. We shouldn't be jumping the gun on updating to the bleeding edge of Thrust/CUB in RMM when interaction with libcudf hasn't been tested. Furthermore, we haven't had a conversation about what we want to do with Thrust/CUB versioning in RAPIDS libraries.

[jrhemstad]

Otherwise the rmm::device_vector falls back to the legacy default stream for some operations.

Users can build RMM against a custom Thrust version if they want to get this fix in the meantime

[rongou]

I agree this can potentially be a big change for cuDF, but I'm not so sure about RMM. The thrust api surface for RMM is pretty small and looks to be stable. Since RMM and cuDF are in two separate repos, this necessarily has to be a two-step process. I can create a PR under cuDF to also pull in the thrust/cub release and let it run through the CI. Would that help?

This is really the first step towards enabling PTDS for Spark. We probably should add some multi-threaded host tests for both RMM and cuDF to verify PTDS behavior. Changing the Spark build with the new thrust release is fine for a prototype, but it's hardly "production ready" when neither RMM or cuDF has been built or tested with the release.

[jrhemstad]

I can create a PR under cuDF to also pull in the thrust/cub release and let it run through the CI. Would that help?

It would be a necessary first step, yes. But that alone isn't enough. We need to decide if we are okay with overriding Thrust that is shipped with the toolkit.

[mtjrider]

@jrhemstad is there a place where discussing thrust override is taking place?

If so, can it be linked to this PR?

[harrism]

@mt-jones the discussion was on slack, can't link it here.

[kkraus14]

@mt-jones the discussion was on slack, can't link it here.

Sounds like we need to open a github issue with a summary of the discussion and current thoughts so that we can have an open conversation.

[leofang]

Sounds like we need to open a github issue with a summary of the discussion and current thoughts so that we can have an open conversation.

@kkraus14 I happened to open one here as you typed! 😂
conda-forge/cub-feedstock#4

[harrism]

Sounds like we need to open a github issue with a summary of the discussion and current thoughts so that we can have an open conversation.

@kkraus14 I happened to open one here as you typed! joy
conda-forge/cub-feedstock#4

@leofang this discussion is about RAPIDS depending on CUB and Thrust from github rather than from the CUDA toolkit, so discussing it on conda-forge would not be appropriate. :) I opened a cuDF issue here: rapidsai/cudf#5346

[harrism]

Merged rapidsai/cudf#5315, so merging this.