Repository navigation
[RFC]: DLPack C Function for Speed Exchange #973
Description
Activity
- changed the title
[-][RFC] DLPack C Function for Speed Exchange[/-][+][RFC]: DLPack C Function for Speed Exchange[/+]on Sep 12, 2025 This makes sense to me in principle. We always had this in mind I believe - get adoption first, and think about a C API if and when performance of Python dunder methods becomes limiting.
When dmlc/dlpack#175 lands in a new DLPack version, I think we can simply reference that in the
from_dlpack,__dlpack__and design_topics/data_interchange docs as a recommendation to implement the C protocol as well.A single new
__c_dlpack_xxxmethod will probably be preferable over multiple methods, but that's already under discussion in dmlc/dlpack#175 as well.Reacted by Tianqi Chen
This is a cross ref RFC on DLPack based exchange. As of now, DLPack exchange relies on python functions such as
tensor.__dlpack__(). While they works well for common cases, the general overhead of such exchange is at the level of 0.2-0.3 us for very well optimized version, and can go up to 0.4-1 us for less optimized implementation.For a function that takes three arguments f(a, b, c), assume we run DLPack exchange for each argument, the general conversion overhead usually gets to around 0.7us - 3us.
While such overhead can be acceptable in many settings, in GPU applications the extra 1-3us overhead can still be significant. For a kernel that takes 2us to finish, 0.7 us means 30% additional overhead in execution
Recently, we propose to develop a set of specific C functions to help DLPack based exchange for array libraries that works on C extensions, please see more context here
dmlc/dlpack#175
In the context of array-api, it would be useful to help standardize the specific field for such speed exchange
mypackage.Tensor.__dlpack_c_exchange_api__Note that the proposed speed exchange function can be used in conjunction with the current DLPack exchange, to gracefully handle fallback cases.