[FEA][DISCUSSION] Require C++17

[harrism]

In 0.20, RAPIDS libraries including libcudf will beginning adopting C++17 features in their implementations and likely require C++17 for their interfaces. We would like to do the same in RMM; however, since RMM is header-only, there is no difference between requiring C++17 for interfaces vs. implementation. (Note RAPIDS will deprecate CUDA 10.x starting with the 0.19 release and require CUDA 11.0 or higher starting with the 0.20 release.)

I'm opening this issue to discuss any concerns with moving to requiring minimum C++17 to compile RMM. This should not affect users CuPy that only interface with the RMM Python API. However, there are other users of RMM C++ outside of core RAPIDS libraries, such as

• https://github.com/BlazingDB/blazingsql (@williamBlazing @felipeblazing)
• https://github.com/psc-code/psc (@germasch)
• https://github.com/rapidsai/xgboost (@hcho3 @JohnZed @trivialfis)
• RMM Cython (@shwina @jakirkham)

Can the people I've tagged above please comment on whether you are OK with RMM requiring C++17 starting in release 0.20?

[hcho3]

I'm okay with it, since RMM is strictly an optional dependency of XGBoost. Users who have an older compiler (GCC 5.x) will be able to build XGBoost without RMM support.

[kkraus14]

cc @shwina @jakirkham for Cython perspective

[shwina]

Not sure if this will affect any of the public APIs that e.g., Python interfaces with. If so, this could potentially be a problem for Cython. Cython does not support many (any?) C++17-specific features. That being said, in many cases, it is possible to write Cython definitions for missingC++17 types/features quite easily. We can explore that on a case-by-case basis (and of course, upstream to Cython if possible).

[jakirkham]

Agree with Ashwin

IIUC this would also be helpful for solving some issues like host_buffer support ( #260 )

[kkraus14]

One thing that comes to mind for public APIs would be moving from thrust::optional to std::optional, so that's something we'd presumably need to support on the Cython side. Ideally we could prevent leaking the Thrust dependency for RMM Cython.

[harrism]

std::optional is the only C++17 feature I'm aware of that impacts the APIs that Cython would interface with.

[harrism]

IIUC this would also be helpful for solving some issues like host_buffer support ( #260 )

Correct using C++17 std::pmr::memory_resource as a base for host memory resources will help with things like host_buffer.

Also, I assume supporting C++17 will make it easier to depend on the device_memory_resource functionality we are in the process of upstreaming to libcu++, which expands on std::pmr functionality (CC @jrhemstad).

[harrism]

Cython does not support many (any?) C++17-specific features.

@shwina Does Cython support compiling with the --std=c++17 option?

[jakirkham]

Looks like there is already a Cython issue about std::optional ( cython/cython#3293 ) and the start of a PR ( cython/cython#3294 )

[shwina]

Yes, we can compile with --std=c++17 (or really, any compiler flags of our choosing).

[felipeblazing]

I don't foresee this being a problem for us though I am guessing some of the changes will require us to do some reworking. We already are going to have to use c++17 for cudf.

[harrism]

@germasch do you have an opinion on this for PSC?

[germasch]

It's not necessarily my preference (neither is requiring CUDA-11) -- in the HPC world, software environments aren't necessarily upgraded all that quickly -- but I can see the point from the perspective of RAPIDS' rapid development ;) I don't think it will cause me any real troubles, though (and if so, I could stick with an older RMM). Thanks for checking!

[harrism]

Totally understand. The RAPIDS team has been waiting for CUDA to support C++17 for a while now. Adoption 4 years after standardization is not super quick. :)

RMM is also trying to better align with C++17 std::pmr::memory_resource

[github-actions]

This issue has been labeled inactive-30d due to no recent activity in the past 30 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed. This issue will be labeled inactive-90d if there is no activity in the next 60 days.

[kkraus14]

This was changed in #741 to require C++17. Closing.