NVIDIA / NVIDIA/cuda-python

[PERF]: Measure the performance potential of caching pre-converted arguments at the call site

Open
#1,655 0 comments 1 reaction 1 assignee View on GitHub

@mdboom is already working on this.

Since Feb 27, 2026.

cuda.bindings experiment performance triage
Dominant language
Cython
Stars
3.4k
Forks
329
Avg merge
1d 23h
Merged PRs (30d)
116

Description

I first came across the idea presented here in this paper: https://drops.dagstuhl.de/storage/00lipics/lipics-vol313-ecoop2024/LIPIcs.ECOOP.2024.6/LIPIcs.ECOOP.2024.6.pdf

The idea is that function calls across a language boundary spend a lot of time converting data structures from one form to another. Particulary in dynamic languages, there are many different code paths to handle many supported data types, but in practice, the types are quite stable between calls even in as the values change. The general idea is that once a particular call gets "hot", you replace a general function that handles all types with one that is specialized for specific types.

If you suppose the following times:

  • T: The total time to convert any acceptable types in a dynamic and fully safe way
  • H: The time to hash the types of the arguments
  • F: The time to convert specific types, in a less safe way

In order for this to work, H + F should be significantly less than T, and the rate at which you see the same types at the same call site needs to be high enough that (T + H)x + (H + F)(1 - x) amortizes to less than T.

We can start by building a prototype to measure T, H, F, and x, and then decide whether it is worth the effort to proceed further.

The best solution is to add support for this "call site caching" to the CPython interpreter (though there are object lifetime issues that made that tricky). It is also possible to do this outside of the CPython interpreter by creating a call-site-to-cache mapping (at the expense of some performance).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.