-
Notifications
You must be signed in to change notification settings - Fork 231
Description
Currently cudf does some automatic memory configuration on startup, specifically around setting up cupy and numba to use rmm. cuml takes a different approach, defining a with_cupy_rmm
decorator that wraps method calls in temporarily setting the cupy memory resource to use rmm using cupy's own context manager. cugraph takes no such action, but since cugraph itself imports cudf it winds up benefiting from cudf's settings.
Now, cudf is considering going further and considering changing the default memory resource, which would implicitly affect cuml and cugraph as well. #2043 is a proposal for how that could be done in a way that is cudf-specific and does not impact other libraries. More generally, however, we need to think about how we do all of these sorts of implicit memory management and configuration in a way that hides details from users who don't need them (what we have optimized for until now) without making decisions in one library that have deleterious effects on other libraries with no recourse (which we have effectively ignored up until now).
For global memory resources, something like #2043 would provide a standardized API for different libraries to maintain their own maps of default mrs, but we should make sure to add a convenience layer for a library to opt in to rmm's default mrs if they so choose. For other configuration like numba and cupy, we should come to some consensus on the way that we want to handle allocations from those libraries when they are used in various RAPIDS libraries. Perhaps we should be exposing something like cuml's context manager in rmm directly for other RAPIDS libraries to use to avoid modifying cupy and numba's global state. On the other hand, if we feel strongly that modifying their state is always the right thing to do, that choice should live in rmm instead of cudf.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status