[FEA]: Define new protocol(s) defining the size of an object in GPU memory
@lijinf2 y travaille déjà.
Depuis le 12/6/2026.
Évaluation
Cette issue n'a pas encore été évaluée.
Description
Is this a duplicate?
- I confirmed there appear to be no duplicate issues for this request and that I agree to the Code of Conduct
Area
cuda.core
Is your feature request related to a problem? Please describe.
This issue is adapted from https://github.com/rapidsai/cudf/issues/9587.
Python's sys module provides the sys.getsizeof function to determine the size of a Python object. This function is not recursive (so given a collection like a list it will not include the memory of each element in the list, which is a reasonable choice since that isn't always a well-defined query with a single answer, e.g. if the underlying objects have overlapping memory ranges), so it is only designed to work on a single object at a time. The behavior of getsizeof when applied to a user-defined class may be customized by overriding the __sizeof__ attribute.
Currently, there is no equivalent method for objects backed by GPU memory. CUDA memory is also more complex than host memory in that there are multiple types of memory that an object may be allocated from, such as managed or pinned memory. Various higher-level Python libraries that leverage GPU libraries under the hood would benefit from a standardized approach to requesting total GPU memory allocations.
Describe the solution you'd like
It would be nice to define a standard protocol like __cuda_sizeof__ that Python objects could implement to indicate how much GPU memory they use. Ideally, the protocol would return something like a dictionary or a dataclass that could indicate memory usage by type (managed, pinned, etc). To fully satisfy this need, we will also need to think about what how this protocol should behave for cases where one object is viewing a subset of the data owned by another object. For example, what would be the expected behavior for slices? Another case to consider would be noncontiguous memory, such as a strided view of an array. There are some cases where the caller may want to know the total memory of the underlying allocation, while at other times the caller may really want to know how much new memory would be allocated by an elementwise copy. We could support both of these using separate protocols, or by using a parametrized protocol. We can also look to existing __sizeof__ implementations on the CPU for prior art.
We would then provide a function cuda.core.getsizeof that would be the canonical implementation of how to use this protocol.
I think the recursive case remains out of scope.
Describe alternatives you've considered
No response
Additional context
No response
- Langage dominant
- Cython
- Étoiles
- 3.4k
- Forks
- 329
- Merge moyen
- 1 j 21 h
- PR mergées (30 j)
- 113
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de NVIDIA/cuda-python
-
bug cuda.core
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
NVIDIA/cuda-python#2886 · 1 commentaire ·
-
triage
Difficulté 1/5 Moins d'une heure Accessibilité débutants 88/100
NVIDIA/cuda-python#2717 ·
-
triage
Difficulté 1/5 1-3 heures Accessibilité débutants 90/100
NVIDIA/cuda-python#2712 ·
-
[BUG]: LocatedHeaderDir is mutable, so callers can poison the cached header-directory lookup Ouvertetriage
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
NVIDIA/cuda-python#2646 · 1 réaction ·
-
cuda.core triage
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
NVIDIA/cuda-python#2435 · 1 commentaire ·