You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Snippet 7: Comment by vzhurba01 — no-tuple version
Method:%timeit
# Version 5 (no tuples, but create new CUdevice):defcuCtxGetDevice():
cdefCUdevicedevice=CUdevice()
err=cydriver.cuCtxGetDevice(<cydriver.CUdevice*>device._pvt_ptr)
iferr==cydriver.cudaError_enum.CUDA_SUCCESS:
returndevicereturndevice# Result: 115 ns ± 0.71 ns per loop
Issue #449: Perf: Reduce StridedMemoryView construction time
Method:%timeit (see Issue #439 for detailed benchmarks)
# This PR implements the fast error code path discussed in Issue #439:# - Dict-based lookup for enum values instead of IntEnum construction# - CUresult(0) went from 282ns to ~20ns via dict lookup# - cuCtxGetDevice went from 390ns to ~150ns
Issue #658: Faster initialization time for cuda.core abstractions
Snippet 1: Issue body — TMA descriptor creation benchmark
Method:time.perf_counter loop
TMA Descriptor Creation Benchmark: Python vs C++
======================================================================
Using CUDA device: NVIDIA H100 80GB HBM3
Python version: 3.14.0
CUDA Python version: 13.0.3
Benchmarking Python TMA descriptor creation (1000 iterations)...
Python - Total: 0.005918s, Average: 5.918μs per iteration
Benchmarking C++ TMA descriptor creation (1000 iterations)...
C++ - Total: 0.000157s, Average: 0.157μs per iteration
Performance Comparison:
------------------------------
C++ is 37.76x faster than Python
Snippet 2: Comment by mdboom — Cython optimization analysis
Method: Cython benchmarking + analysis
## Accessing values of enums# Instead of:cdefcydriver.CUtensorMapInterleavecyinterleave=interleave.value# Doing this:cdefcydriver.CUtensorMapInterleavecyinterleave=int(interleave)
# reduces function call overhead by about 25%## Converting short lists/tuples of driver.cuuint32_t values# Changing generator expression to for loop + direct type check:# reduces overhead by another 10%## Static allocation for small arrays (instead of heap):cdefcydriver.cuuint32_t[5] elementStridesStatic# gives another 25% speedup
Snippet 2: Comment by shwina — mempool release threshold workaround
Method:functools.cache + driver API
@functools.cachedef_set_default_mempool_threshold(device_id: int):
"""Set the release threshold for the default memory pool on this device. Prevents the driver from shrinking the pool after every sync (which is slow)."""default_pool=handle_return(driver.cuDeviceGetDefaultMemPool(device_id))
threshold=handle_return(
driver.cuMemPoolGetAttribute(default_pool,
driver.CUmemPool_attribute.CU_MEMPOOL_ATTR_RELEASE_THRESHOLD))
ifint(threshold) ==0:
handle_return(driver.cuMemPoolSetAttribute(default_pool,
driver.CUmemPool_attribute.CU_MEMPOOL_ATTR_RELEASE_THRESHOLD,
driver.cuuint64_t(0xFFFFFFFFFFFFFFFF)))
# Before: 1.23 us +- 0.06 us
# After: 1.02 us +- 0.06 us
#
# Measured using pyperf: pyperf command --fast python -c "..."
# Two changes:
# 1. Refactor versioned/non-versioned paths to reduce branches
# 2. Create shape and strides tuples using Python/C API
Issue #898: Generator expressions in Cython create overhead
Snippet 1: Comment by mdboom — generator vs for loop comparison
Method: code analysis
# Generator expression (slow in Cython):ifnotall(isinstance(_x, (CUlibraryOption)) for_xinlibraryOptions):
raiseTypeError(...)
# Better as plain for loop (Cython generates much tighter code):for_xinlibraryOptions:
ifnotisinstance(_x, (CUlibraryOption)):
raiseTypeError(...)
# Generators create separate Python extension functions,# which are significantly more expensive than C for loops in Cython.
PR #940: Remove generator expressions from input validation
# type() is is faster than isinstance() for exact type checks:In [1]: %timeitisinstance(x, int)
50ns ± 0.5nsperloopIn [2]: %timeittype(x) isint25ns ± 0.3nsperloop
Snippet 1: PR context — IntEnum construction overhead
Method:%timeit
# stdlib IntEnum construction is very slow:In [2]: %timeitdriver.CUresult(0)
282ns ± 5.81nsperloop# This PR replaces it with a faster pure Python enum implementation.# Key insight: enum.IntEnum inherits from int, so int(enum_val) is fast,# but CUresult(0) (constructing from value) goes through slow Enum machinery.
Additional Performance-Related Items
The following items discuss performance but without standalone benchmark snippets:
Activity
leofang commentedon Feb 10, 2026
Data mining proudly carried out by Copilot.
Benchmark Snippets Collection — NVIDIA/cuda-python
Collected timing scripts and benchmark snippets from issues and PRs in the
NVIDIA/cuda-python repository.
Summary Table
StridedMemoryViewconstruction timedev.compute_capabilityDeviceconstructor@functools.lru_cacheforget_binding_version()cuda.bindings.nvrtcaffected by GILcuda.coreabstractionscuda-bindings3x slower than C++Device.set_current()is slowBufferDevice.set_current()fastercuda.bindingsbenchmarks_launch_config.pyisinstance(obj, T)withtype(obj) is Tlaunch&LaunchConfigmoreDetailed Benchmark Snippets
Issue #439: Querying current device is slow compared to CuPy
Link: #439
Snippet 1: Issue body — Device() and compute_capability comparison
Method:
%timeitSnippet 2: Comment by leofang — compute_capability with dict cache
Method:
%timeitSnippet 3: Comment by leofang — runtime vs driver vs CuPy
Method:
%timeitSnippet 4: Comment by rwgk — Device() before/after diff
Method: manual comparison
Snippet 5: Comment by vzhurba01 — detailed Cython cuCtxGetDevice versions
Method:
%timeit(multiple Cython variants)Snippet 6: Comment by leofang — dict lookup vs IntEnum construction
Method:
%timeitSnippet 7: Comment by vzhurba01 — no-tuple version
Method:
%timeitIssue #449: Perf: Reduce
StridedMemoryViewconstruction timeLink: #449
Snippet 1: Issue body — StridedMemoryView overhead breakdown
Method:
%timeit, profilingPR #459: Improve perf of accessing
dev.compute_capabilityLink: #459
Snippet 1: PR body — before/after
Method:
%timeitPR #460: Switch to use CUDA driver APIs in
DeviceconstructorLink: #460
Snippet 1: PR body — before/after
Method:
%timeitPR #512: Add
@functools.lru_cacheforget_binding_version()Link: #512
Snippet 1: PR body — before/after
Method:
%timeitPR #546: Fast error code (closes #439)
Link: #546
Snippet 1: PR context — fast error code path
Method:
%timeit(see Issue #439 for detailed benchmarks)Issue #658: Faster initialization time for
cuda.coreabstractionsLink: #658
Snippet 1: Issue body — Device/Stream/Event creation comparison
Method:
timeit.timeitSnippet 2: Comment by leofang — Event creation detailed analysis
Method:
%timeitSnippet 3: Comment by leofang — line_profiler output for Event._init
Method:
line_profilerSnippet 4: Comment by leofang — Stream creation comparison
Method:
%timeitIssue #659: CUDA API calls through
cuda-bindings3x slower than C++Link: #659
Snippet 1: Issue body — TMA descriptor creation benchmark
Method:
time.perf_counterloopSnippet 2: Comment by mdboom — Cython optimization analysis
Method: Cython benchmarking + analysis
PR #677: [DONT MERGE] Make stream creation faster
Link: #677
Snippet 1: PR body — flame chart analysis (speed-of-light implementation)
Method: flame charts, profiling
PR #709: Cythonize away some perf hot spots
Link: #709
Snippet 1: PR body — Cythonized hot spots
Method: profiling, flame charts
Issue #739:
Device.set_current()is slowLink: #739
Snippet 1: Issue body
Method:
%timeitIssue #756: Cythonize
BufferLink: #756
Snippet 1: Comment by shwina — Buffer allocation vs CuPy vs raw bindings
Method:
%timeitSnippet 2: Comment by shwina — mempool release threshold workaround
Method:
functools.cache+ driver APIPR #781: Make
Device.set_current()fasterLink: #781
Snippet 1: PR body — before/after
Method:
%timeitPR #838: Improve StridedMemoryView creation time
Link: #838
Snippet 1: PR body — pyperf results
Method:
pyperfIssue #898: Generator expressions in Cython create overhead
Link: #898
Snippet 1: Comment by mdboom — generator vs for loop comparison
Method: code analysis
PR #940: Remove generator expressions from input validation
Link: #940
Snippet 1: Comment by cpcloud — pytest-benchmark results
Method:
pytest-benchmarkSnippet 2: Comment by leofang — nvrtcCreateProgram stress test script
Method:
time.perf_counterPR #876: Cythonize Buffer and MemoryResource classes
Link: #876
Snippet 1: PR body — allocation benchmarks
Method:
%timeitPR #1221: Cythonize
_launch_config.pyLink: #1221
Snippet 1: Comment by leofang — LaunchConfig benchmark suggestion
Method:
%timeitPR #1274: Cythonize device memory resource attributes
Link: #1274
Snippet 1: PR body — DeviceMemoryResource benchmark
Method:
%timeitPR #1292: Replace
isinstance(obj, T)withtype(obj) is TLink: #1292
Snippet 1: PR body — isinstance vs type() is
Method:
%timeitPR #1390: Cythonize
launch&LaunchConfigmoreLink: #1390
Snippet 1: PR body — launch benchmark before/after
Method:
%timeitSnippet 2: Comment by leofang — comparison with cuda.bindings
Method:
%timeitPR #1581: Faster enum implementation (Pure Python)
Link: #1581
Snippet 1: PR context — IntEnum construction overhead
Method:
%timeitAdditional Performance-Related Items
The following items discuss performance but without standalone benchmark snippets:
Key Performance Themes
CUresult(0)costs ~282ns vs ~20ns for dict lookup (Querying current device is slow compared to CuPy #439, fast error code #546, Faster enum implementation (Pure Python version) #1581)cudaGetDevice()call (Querying current device is slow compared to CuPy #439, Improve perf of accessingdev.compute_capability#459, Switch to use CUDA driver APIs inDeviceconstructor #460)preconditiondecorator,check_or_create_options([FEA]: Faster initialization time forcuda.coreabstractions #658, [DONT MERGE] Make stream creation faster #677, Cythonize away some perf hot spots #709)Buffer#756, Cythonize Buffer and MemoryResource classes for performance optimization #876)cuda-bindings3x slower than direct CUDA C++ API calls #659)StridedMemoryViewconstruction time #449, Improve #449: Improve StridedMemoryView creation time #838)launch&LaunchConfigmore #1390)leofang commentedon Jul 2, 2026
Q: @danielfrg is this done with #2005, or are there anything we should follow up?
danielfrg commentedon Jul 2, 2026
No, this is done now. Closing.