[PERF]: Measure the performance potential of caching pre-converted arguments at the call site
@mdboom arbeitet bereits daran.
Seit 27.2.2026.
Bewertung
Dieses Issue wurde noch nicht bewertet.
Beschreibung
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).
- Vorherrschende Sprache
- Cython
- Sterne
- 3.4k
- Forks
- 329
- Ø Merge
- 1 T. 21 Std.
- Gemergte PRs (30 T.)
- 113
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus NVIDIA/cuda-python
-
bug cuda.core
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
NVIDIA/cuda-python#2886 · 1 Kommentar ·
-
triage
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
NVIDIA/cuda-python#2717 ·
-
triage
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 90/100
NVIDIA/cuda-python#2712 ·
-
triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
NVIDIA/cuda-python#2646 · 1 Reaktion ·
-
cuda.core triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100
NVIDIA/cuda-python#2435 · 1 Kommentar ·