Generated banner for Optimize For Gpu
Generated logo for Optimize For Gpu

Optimize For Gpu

K-DenseCommunityCreated by K-Dense, Inc.

  • Skill
  • Tool integration
  • Science and research
  • MIT
  • No issues found

From the author

GPU-accelerates scientific Python on NVIDIA hardware and verifies that the result is correct and faster. Use for CUDA/GPU optimization; CPU-bound NumPy, SciPy, pandas, scikit-learn, NetworkX, scikit-image, vector-search, image-processing, graph, simulation, or file-I/O workloads; CuPy, cuDF, cuML, cuGraph, cuVS, cuCIM, KvikIO, Warp, Newton, Numba-CUDA, or RAFT questions; and profiling, memory-transfer, kernel, or multi-GPU bottlenecks. Also use when large data-parallel Python code is slow and GPU acceleration is a plausible option, even if the user does not name CUDA.
— the description by K-Dense, Inc.

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a systematic approach to GPU-accelerating CPU-bound scientific Python code. It emphasizes an evidence-driven workflow: profiling existing bottlenecks, selecting the appropriate library (e.g., CuPy, cuDF, cuML, cuGraph, cuCIM, or Warp), and validating performance gains through synchronized benchmarks. It guides users to maintain numerical contracts, minimize host-device data transfers, and choose the least disruptive implementation path—from backend acceleration modes to custom Numba-CUDA kernels.

What it does

  • Identifies CPU-bound bottlenecks in NumPy, pandas, and scikit-learn workflows.
  • Maps scientific tasks to GPU-accelerated libraries like CuPy, cuDF, and cuML.
  • Provides patterns for migrating CPU code to GPU-resident execution.
  • Guides the implementation of custom CUDA kernels for specialized simulation or processing.
  • Ensures correctness through comparative testing and numerical tolerance validation.
  • Facilitates accurate benchmarking using CUDA events and profilers.

When to use it

  • When processing large datasets that exceed CPU performance limits.
  • When working with compute-intensive tasks like image processing, graph analytics, or simulations.
  • When the workload involves data-parallel operations suitable for NVIDIA GPU architecture.
  • When you need to optimize existing Python code without rewriting the entire application.
  • When you require high-performance file I/O directly into GPU memory.

Advantages

  • Significant speedups for data-parallel scientific computations.
  • Maintains familiar Python API patterns through library-specific drop-in replacements.
  • Reduces overhead by keeping data resident on the GPU.
  • Provides a clear decision framework for choosing between high-level libraries and custom kernels.
  • Promotes rigorous validation to ensure GPU results match CPU expectations.

Usage examples

“How can I speed up my pandas groupby operation on a large dataset using my NVIDIA GPU?”
The agent will guide you to use cuDF, either by replacing the import or using the cudf.pandas accelerator mode, and explain how to benchmark the end-to-end performance.
“I have a slow Python loop performing particle integration. Can I run this on a GPU?”
The agent will recommend using NVIDIA Warp to JIT-compile the loop into a GPU kernel, providing a pattern for the integration function and explaining how to manage device memory.
“My scikit-learn random forest training is too slow. What are my options?”
The agent will suggest using cuML's RandomForestClassifier, explain the parameter matching process, and advise on how to validate the model's accuracy against the CPU version.
“How do I profile my GPU code to ensure I am actually getting a speedup?”
The agent will provide instructions on using CUDA events for synchronization, the cupyx.profiler for micro-benchmarking, and Nsight Systems for end-to-end timeline analysis.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/k-dense-ai/optimize-for-gpu/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip optimize-for-gpu.zip -d .agents/skills

Documentation by K-Dense, Inc.

GPU Optimization for Python with NVIDIA

Treat GPU acceleration as an evidence-driven optimization, not an automatic rewrite. Preserve the user's numerical and algorithmic contract, measure with representative data, and keep the GPU version only when synchronized end-to-end benchmarks show a useful improvement.

Reviewed against RAPIDS 26.08, CuPy 14.2, Numba-CUDA 0.30.4, and Warp 1.17. The references contain illustrative GPU examples: source/API review is not execution on CUDA hardware. Validate them on the user's target GPU before reporting correctness or speedup. Do not use a moving latest documentation page to infer compatibility with a pinned release.

When This Skill Applies

  • User wants to speed up numerical/scientific Python code

  • User is working with large arrays, matrices, or dataframes

  • User mentions CUDA, GPU, NVIDIA, or parallel computing

  • User has NumPy, pandas, SciPy, scikit-learn, NetworkX, or scipy.sparse.linalg code that processes large datasets

  • User needs low-level GPU primitives (sparse eigensolvers, device memory management, multi-GPU communication)

  • User is doing machine learning (training, inference, hyperparameter tuning, preprocessing)

  • User is doing graph analytics (centrality, community detection, shortest paths, PageRank, etc.)

  • User is doing vector search, nearest neighbor search, similarity search, or building a RAG pipeline

  • User has Faiss, Annoy, ScaNN, or sklearn NearestNeighbors code that could be GPU-accelerated

  • User wants GPU-accelerated interactive dashboards, cross-filtering, or exploratory data analysis on large datasets

  • User is doing geospatial analysis (point-in-polygon, spatial joins, trajectory analysis, distance calculations) with GeoPandas or shapely

  • User is doing image processing, computer vision, or medical imaging (filtering, segmentation, morphology, feature detection) with scikit-image or OpenCV

  • User is working with whole-slide images (WSI), digital pathology, microscopy, or remote sensing imagery

  • User is loading large binary data files into GPU memory (numpy.fromfile → cupy, or Python open() → GPU array)

  • User needs to read files from S3, HTTP, or WebHDFS directly into GPU memory

  • User mentions GPUDirect Storage (GDS) or wants to bypass CPU-memory staging for file IO

  • User is doing physics simulation (particles, cloth, fluids, rigid bodies) or differentiable simulation

  • User needs mesh operations (ray casting, closest-point queries, signed distance fields) or geometry processing on GPU

  • User is doing robotics (kinematics, dynamics, control) with transforms and quaternions

  • User has Python simulation loops that could be JIT-compiled to GPU kernels

  • User mentions NVIDIA Warp or wants differentiable GPU simulation integrated with PyTorch/JAX

  • User is doing simulations, signal processing, financial modeling, bioinformatics, physics, or any compute-intensive work

  • User wants to optimize existing code and GPU acceleration is the right answer

Choose the Smallest Suitable Layer

Prefer a maintained library implementation over a custom kernel:

Existing workloadPreferred pathUse for
NumPy / SciPyCuPyarrays, sparse matrices, linear algebra, FFTs, signal processing
pandascudf.pandas, then cuDFaccelerator mode first; native API for more control
scikit-learncuml.accel, then cuMLaccelerator mode first; native estimators as needed
NetworkXnx-cugraph, then cuGraphbackend dispatch first; native graph API at scale
scikit-imagecuCIMGPU image processing and whole-slide imaging
Faiss / Annoy / k-NNcuVSexact and approximate vector search
Raw or remote file I/OKvikIOGPU buffers and GPUDirect Storage
Custom array kernelsNumba-CUDA-MLIR for new work; Numba-CUDA for existing codeexplicit SIMT kernels and shared memory
Spatial or differentiable kernelsWarpgeometry, simulation kernels, robotics, autodiff
High-level physics simulationNewtonmaintained engine that succeeds the removed warp.sim module
Low-level RAPIDS primitivesRAFT (pylibraft)sparse eigensolvers, resources, multi-GPU building blocks

Do not move code out of PyTorch, JAX, TensorFlow, or another GPU-native framework merely to use one of these libraries. First remove CPU round trips and use the framework's compiler, profiler, mixed-precision, and batching facilities.

Treat these as legacy-only:

ProjectStatusGuidance
cuxfilterFinal release 26.06Maintain existing dashboards only. For new work, combine cuDF with HoloViews/hvPlot/Datashader and serve with Panel, Dash, Streamlit, or Bokeh.
cuSpatialArchived at 25.04Use only in an isolated legacy environment. For new work, keep geometry in GeoPandas/Shapely and accelerate compatible tabular stages with cuDF.

Full per-library guidance, including when each is the wrong choice and how to combine them, is in references/decision_framework.md. Install commands and CUDA version selection are in references/installation.md. Before/after conversions for every library are in references/code_transformation_patterns.md.

Optimization Workflow

1. Define the contract and baseline
  • Capture a representative input, expected output, and acceptable numerical tolerance.

  • Measure the current end-to-end path, including input, transfers, compute, and output.

  • Profile before changing code. Use CPU profilers for CPU code and identify whether the real limit is compute, memory bandwidth, allocation, transfer, synchronization, or storage.

  • Record hardware, package versions, dtypes, shapes, batch size, and warm-up policy with results.

2. Check suitability before porting

GPU execution is promising when the hot path exposes substantial independent work, runs often enough to amortize initialization and transfer, and has a working set that fits available device memory with room for temporaries. Keep a CPU path when the workload is small, mostly sequential, dominated by unsupported operations, or requires frequent host-device round trips.

Do not use fixed row-count thresholds as proof. Benchmark the user's actual shapes and hardware. For out-of-core data, estimate peak working memory and choose chunking, Dask, or a streaming design before allocating.

3. Try the least disruptive implementation
  1. If the code already uses a GPU-native framework, optimize within that framework.

  2. Try accelerator or backend modes (cudf.pandas, cuml.accel, nx-cugraph).

  3. Move to a native GPU API only where accelerator coverage or performance is insufficient.

  4. Write a custom kernel only when profiling shows an operation without a suitable library implementation.

Read the relevant library reference before writing code; compatible names can still differ in defaults, dtypes, output types, and supported arguments.

4. Keep a coherent GPU data path
  • Transfer inputs once and keep intermediates device-resident.

  • Reuse allocations and prefer out= or in-place forms when semantics allow.

  • Batch small operations; fuse elementwise work when it removes intermediate arrays.

  • Use pinned host memory and non-default streams only after profiling shows transfer overlap matters.

  • Choose float32, mixed precision, or reduced-precision storage only when the contract permits it.

5. Validate semantics before speed
  • Compare CPU and GPU outputs on small deterministic fixtures and representative data.

  • Use explicit tolerances for floating-point results and test edge cases, NaNs, ordering, and dtypes.

  • For approximate nearest-neighbor indexes, report recall@k against exact search; do not compare an exact CPU algorithm with an approximate GPU algorithm as if they were equivalent.

  • Check accelerator warnings and logs for CPU fallback.

6. Benchmark GPU code correctly

GPU work is asynchronous, so a CPU timer around an unsynchronized call measures enqueue time. Warm up context creation and JIT compilation, then use CUDA events or a library-aware timer:

from cupyx.profiler import benchmark

print(benchmark(gpu_function, (arg1, arg2), n_warmup=10, n_repeat=100))

Use %gpu_timeit in notebooks, Nsight Systems (nsys) for end-to-end timelines, and Nsight Compute (ncu) for kernel analysis. Report both synchronized kernel/region time and realistic end-to-end latency; include transfer and conversion costs when production pays them.

Measure peak device memory as well as time. For CuPy, distinguish live allocations from memory retained by its pool; a high nvidia-smi reading after arrays are released is not by itself a leak. Record the allocator and pooling policy, include temporary buffers and FFT caches, and leave headroom for CUDA context/library allocations outside the pool limit. Avoid clearing the pool inside timed repeats unless production does so. See CuPy memory management.

7. Keep, revise, or reject the port

Retain the GPU path only when it passes correctness checks and improves the metric the user cares about on representative data. If it does not, explain whether the limiting factor is problem size, transfers, unsupported fallback, memory pressure, launch granularity, or the algorithm itself.

Important Notes

  • Provide a CPU fallback when the application requires portability; otherwise fail early with a clear hardware and dependency error.

  • Test against a trusted reference with problem-specific tolerances; changed algorithms, precision, reduction order, and random streams can produce more than roundoff differences.

  • GPU memory is limited — for datasets larger than GPU memory, consider chunking or using RAPIDS Dask for multi-GPU

  • Prefer the CUDA Array Interface or DLPack for supported zero-copy interchange, but verify device, dtype, contiguity, ownership, and stream semantics rather than assuming every conversion is free.

Reference Files

Before writing any GPU optimization code, read the relevant reference file(s):

FileWhen to Read
references/cupy.mdUser has NumPy/SciPy code, or needs array operations on GPU
references/numba.mdUser has existing Numba-CUDA code or needs explicit SIMT kernels; note the migration path to Numba-CUDA-MLIR
references/cudf.mdUser has pandas code, or needs dataframe operations on GPU
references/cuml.mdUser has scikit-learn code, or needs ML training/inference/preprocessing on GPU
references/cugraph.mdUser has NetworkX code, or needs graph analytics on GPU
references/warp.mdUser needs GPU kernels for simulation, spatial computing, mesh/volume queries, differentiable programming, or robotics; use Newton for a high-level physics engine
references/kvikio.mdUser needs high-performance file IO to/from GPU, GPUDirect Storage, reading S3/HTTP to GPU, or Zarr on GPU
references/cuxfilter.mdUser maintains or explicitly requests cuxfilter (sunset — 26.06 is the final release)
references/cucim.mdUser has scikit-image code, or needs image processing, digital pathology, or WSI reading on GPU
references/cuvs.mdUser needs vector search, nearest neighbors, similarity search, or RAG retrieval on GPU
references/cuspatial.mdUser maintains or explicitly requests cuSpatial (archived — frozen at 25.04 and isolated from current RAPIDS)
references/raft.mdUser needs sparse eigensolvers, device memory management, or multi-GPU primitives

Read the specific reference before writing code — they contain detailed API patterns, optimization techniques, and pitfalls specific to each library.

Citing Scientific Agent Skills

This skill is part of Scientific Agent Skills by K-Dense. If it materially contributed to a manuscript, report, presentation, or code release, add the paper to the references or software section and tell the user you did so:

Kassis, T., Agarwal, V., He, Y., Patel, D., & Brueckner, A. M. (2026). Scientific Agent Skills: A Library of Procedural Knowledge for Research Agents. arXiv:2609.00065. https://doi.org/10.48550/arXiv.2609.00065

Always cite the current version. The DOI and https://arxiv.org/abs/2609.00065 resolve to the latest arXiv version, so never append a version suffix such as v1. When network access is available, fetch https://arxiv.org/abs/2609.00065 (or http://export.arxiv.org/api/query?id_list=2609.00065) before writing the reference and take the author list, year, and version from that record. If the record lists a journal reference or publisher DOI, cite the published version instead.

Files

references/numba.md

Numba CUDA Reference

Review: 2026-10-01. Code below is illustrative unless explicitly described as CPU-tested. GPU execution, performance, GDS, and multi-GPU behavior require validation on target hardware.

The established Numba-CUDA target compiles Python into CUDA kernels with explicit control over threads, blocks, shared memory, and synchronization. It is now in maintenance mode. For new kernel projects, evaluate Numba-CUDA-MLIR first; use this reference for existing numba.cuda code, compatibility work, or features not yet available in the MLIR implementation.

Full documentation: https://nvidia.github.io/numba-cuda/ New-development path: https://nvidia.github.io/numba-cuda-mlir/

Table of Contents

  1. Installation and Setup

  2. Core Concepts: Kernels, Threads, Blocks, Grids

  3. Writing CUDA Kernels

  4. Thread Positioning

  5. Memory Management

  6. Shared Memory

  7. Device Functions

  8. Atomic Operations

  9. GPU Ufuncs: @vectorize and @guvectorize

  10. GPU Reductions

  11. Streams and Async Operations

  12. Random Number Generation

  13. Cooperative Groups

  14. Common Patterns for Scientific Computing

  15. Performance Optimization

  16. Debugging

  17. Interoperability

  18. Common Pitfalls


Installation and Setup

Use uv add in standalone examples; follow the user's existing project package manager when one is already configured.

uv add "numba-cuda[cu12]==0.30.*"    # For CUDA 12.x (pulls in numba and CUDA components)
uv add "numba-cuda[cu13]==0.30.*"    # For CUDA 13.x

The NVIDIA numba-cuda package is the out-of-tree implementation of the established numba.cuda target (Numba's built-in target is deprecated). It keeps the numba.cuda namespace and depends on numba, so a single install command suffices. NVIDIA limits this implementation to security and critical fixes through the CUDA 13 lifetime; new feature development targets the separate numba-cuda-mlir package. Follow its migration guide before choosing a compiler for new code because feature coverage continues to evolve.

Requirements: CUDA Toolkit 12 or 13. GPU with Compute Capability >= 5.0 (Maxwell or newer) on CUDA 12, or >= 7.5 (Turing or newer) on CUDA 13.

from numba import cuda

# Verify GPU is available
print(cuda.is_available())   # True if CUDA works
cuda.detect()                # Prints GPU details

Core Concepts

CUDA organizes parallel execution in a hierarchy:

Grid (of blocks) → Blocks (of threads) → Threads
  • Thread: The smallest unit of execution. Each runs your kernel function.

  • Block: A group of threads that can share fast on-chip memory and synchronize with each other. Max 1024 threads per block.

  • Grid: The collection of all blocks for a kernel launch.

A kernel is a function that runs on the GPU, launched from the CPU. A device function runs on the GPU but is called from other GPU code (not from CPU).


Writing CUDA Kernels

The @cuda.jit Decorator
from numba import cuda

@cuda.jit
def my_kernel(input_array, output_array):
    i = cuda.grid(1)                    # Get this thread's global index
    if i < input_array.size:            # Bounds check — ALWAYS do this
        output_array[i] = input_array[i] * 2.0

Key parameters for @cuda.jit:

ParameterPurpose
device=TrueMakes this a device function (callable from GPU only, can return values)
fastmath=TrueEnables fast math (fast sqrt, division, FMA, trig/exp/log approximations on float32). Use when IEEE-754 strictness isn't required
max_registers=NLimits registers per thread to increase occupancy
cache=TrueCaches compiled kernel to disk
debug=TrueEnables exception checking (slow — for debugging only, pair with opt=False)
lineinfo=TrueSource line info for profiling without full debug overhead
Launching Kernels
import numpy as np
from numba import cuda

data = np.random.rand(1_000_000).astype(np.float32)
out = np.zeros_like(data)

# Transfer to GPU
d_data = cuda.to_device(data)
d_out = cuda.device_array_like(out)

# Calculate launch configuration
threads_per_block = 256
blocks_per_grid = (data.size + threads_per_block - 1) // threads_per_block

# Launch
my_kernel[blocks_per_grid, threads_per_block](d_data, d_out)

# Get results back
result = d_out.copy_to_host()

Launch syntax: kernel[grid_dim, block_dim, stream, dynamic_shared_mem_bytes](...args)

The 3rd and 4th parameters are optional (stream and dynamic shared memory size in bytes).

2D Launch Configuration
@cuda.jit
def kernel_2d(matrix, output):
    x, y = cuda.grid(2)
    if x < matrix.shape[0] and y < matrix.shape[1]:
        output[x, y] = matrix[x, y] * 2.0

threads = (16, 16)
blocks = (
    (matrix.shape[0] + threads[0] - 1) // threads[0],
    (matrix.shape[1] + threads[1] - 1) // threads[1],
)
kernel_2d[blocks, threads](d_matrix, d_output)
Convenience: .forall() for 1D
# Automatically computes grid dimensions for 1D
my_kernel.forall(len(data))(d_data, d_out)
Critical Rules for Kernels
  1. Kernels CANNOT return values. All output must be written to arrays passed as arguments.

  2. Always check array bounds. If grid_size > array_size, out-of-bounds threads corrupt memory silently.

  3. Kernel launches are asynchronous. Use cuda.synchronize() before reading results on the CPU.


Thread Positioning

Intrinsics
IntrinsicDescription
cuda.threadIdx.x/y/zThread index within its block
cuda.blockIdx.x/y/zBlock index within the grid
cuda.blockDim.x/y/zThreads per block
cuda.gridDim.x/y/zBlocks in the grid
cuda.grid(ndim)Absolute position in entire grid (1D → int, 2D/3D → tuple)
cuda.gridsize(ndim)Total number of threads in entire grid
Grid-Stride Loop Pattern

For processing data larger than the grid, use a grid-stride loop. This decouples grid size from problem size and is essential for reusing RNG states.

@cuda.jit
def process_large(data, out):
    start = cuda.grid(1)
    stride = cuda.gridsize(1)
    for i in range(start, data.shape[0], stride):
        out[i] = data[i] * 2.0

Memory Management

Data Transfer
# Host → Device
d_array = cuda.to_device(numpy_array)                    # Synchronous copy
d_array = cuda.to_device(numpy_array, stream=stream)     # Async copy

# Allocate on device (no copy)
d_array = cuda.device_array(shape=(1000,), dtype=np.float32)
d_array = cuda.device_array_like(numpy_array)

# Device → Host
host_array = d_array.copy_to_host()                      # New array
d_array.copy_to_host(existing_array)                     # Into pre-allocated
d_array.copy_to_host(stream=stream)                      # Async
Memory Types
TypeAPIUse Case
Devicecuda.device_array(), cuda.to_device()Standard GPU memory
Pinnedcuda.pinned_array(), cuda.pinned() context managerPage-locked host memory — faster transfers
Mappedcuda.mapped_array()Accessible from both host and device
Managedcuda.managed_array()Unified memory — auto-migrates between host/device (Linux/x86 recommended)
Constantcuda.const.array_like(arr)Read-only, cached, set from host
Pinned Memory for Fast Transfers
# Allocate pinned host memory (page-locked — faster PCI-e transfers)
with cuda.pinned(host_array):
    d_array = cuda.to_device(host_array, stream=stream)
    # Transfer is faster because the OS can't page this memory out

# Or allocate directly
pinned = cuda.pinned_array(shape=(1000,), dtype=np.float32)
Deallocation Control
with cuda.defer_cleanup():
    # All GPU deallocation deferred here — avoids implicit synchronization
    # Use this in performance-critical sections
    run_many_kernels()
# Cleanup happens here

Shared Memory

Shared memory is fast on-chip memory (tens of TB/s bandwidth) shared within a block. It's the key to high-performance kernels — use it to cache data that multiple threads in a block will access.

Static Shared Memory (size known at compile time)
from numba import cuda, float32

@cuda.jit
def kernel_with_shared(data, output):
    # Allocate shared memory — visible to all threads in this block
    shared = cuda.shared.array(256, dtype=float32)

    tid = cuda.threadIdx.x
    i = cuda.grid(1)

    # Each thread loads one element into shared memory
    if i < data.size:
        shared[tid] = data[i]
    else:
        shared[tid] = 0.0

    # BARRIER: wait for ALL threads in block to finish loading
    cuda.syncthreads()

    # Now safe to read any element in shared[]
    if i < data.size:
        output[i] = shared[tid] + (shared[tid - 1] if tid > 0 else 0.0)
Dynamic Shared Memory (size set at launch)
@cuda.jit
def kernel_dynamic_shared(data):
    # size=0 means "use dynamic shared memory"
    dyn = cuda.shared.array(0, dtype=float32)
    tid = cuda.threadIdx.x
    i = cuda.grid(1)
    dyn[tid] = data[i] if i < data.size else 0.0
    cuda.syncthreads()
    # ...

# Specify size at launch (4th parameter = bytes)
kernel_dynamic_shared[blocks, threads, stream, 1024](data)  # 1024 bytes of shared mem

Important: All cuda.shared.array(0, ...) calls in the same kernel alias the same memory region. To use multiple dynamic shared arrays, take disjoint slices manually.

Local Memory (per-thread scratchpad)
@cuda.jit
def kernel_with_local(data):
    # Each thread gets its own private array
    local_buf = cuda.local.array(10, dtype=float32)
    i = cuda.grid(1)
    for j in range(10):
        idx = i * 10 + j
        local_buf[j] = data[idx] if idx < data.size else 0.0
    # Process local_buf...

Device Functions

Device functions run on the GPU and are called from kernels or other device functions. Unlike kernels, they can return values.

@cuda.jit(device=True)
def compute_distance(x1, y1, x2, y2):
    return math.sqrt((x2 - x1)**2 + (y2 - y1)**2)

@cuda.jit
def kernel(points, distances):
    i = cuda.grid(1)
    if i < points.shape[0] - 1:
        distances[i] = compute_distance(
            points[i, 0], points[i, 1],
            points[i+1, 0], points[i+1, 1]
        )

CPU @numba.jit dispatchers are not CUDA device functions. If CPU and GPU paths need the same formula, keep a small undecorated source function and create explicit CPU (@njit) and GPU (@cuda.jit(device=True)) implementations or wrappers; test them against the same fixtures.


Atomic Operations

Atomics ensure thread-safe updates to shared data. All return the old value.

cuda.atomic.add(array, index, value)       # +=   (int32, float32, float64)
cuda.atomic.sub(array, index, value)       # -=   (int32, float32, float64)
cuda.atomic.max(array, index, value)       # max  (int/uint 32/64, float 32/64)
cuda.atomic.min(array, index, value)       # min  (same types)
cuda.atomic.nanmax(array, index, value)    # max ignoring NaN
cuda.atomic.nanmin(array, index, value)    # min ignoring NaN
cuda.atomic.and_(array, index, value)      # &=   (int/uint 32/64)
cuda.atomic.or_(array, index, value)       # |=   (int/uint 32/64)
cuda.atomic.xor(array, index, value)       # ^=   (int/uint 32/64)
cuda.atomic.exch(array, index, value)      # exchange
cuda.atomic.cas(array, index, old, value)  # compare-and-swap

Multi-dimensional indexing works via tuples: cuda.atomic.add(result, (row, col), value)

Example: Histogram
@cuda.jit
def histogram(data, bins, min_value, max_value):
    i = cuda.grid(1)
    if i < data.size:
        value = data[i]
        n_bins = bins.size
        if min_value <= value <= max_value:
            bin_idx = int((value - min_value) * n_bins / (max_value - min_value))
            if bin_idx == n_bins:  # Include the rightmost edge.
                bin_idx = n_bins - 1
            cuda.atomic.add(bins, bin_idx, 1)

Validate max_value > min_value on the host before launch. For production histograms, prefer CuPy/CUB unless a custom binning rule is required.


GPU Ufuncs

@vectorize — Element-wise Operations on GPU

The simplest way to run element-wise operations on GPU. Write a scalar function, Numba broadcasts it over arrays automatically.

from numba import vectorize, float32, float64
import math

@vectorize([float32(float32, float32),
            float64(float64, float64)],
           target='cuda')
def gpu_hypot(x, y):
    return math.sqrt(x**2 + y**2)

# Usage — just call it like a NumPy ufunc
result = gpu_hypot(array_x, array_y)

# Pass device arrays to avoid transfers
d_x = cuda.to_device(x)
d_y = cuda.to_device(y)
d_result = gpu_hypot(d_x, d_y)
@guvectorize — Generalized Ufuncs

For operations on sub-arrays (not just scalars). Uses NumPy's generalized ufunc signature.

from numba import guvectorize, float32

@guvectorize([(float32[:,:], float32[:,:], float32[:,:])],
             '(m,n),(n,p)->(m,p)', target='cuda')
def gpu_matmul(A, B, C):
    for i in range(A.shape[0]):
        for j in range(B.shape[1]):
            total = 0.0
            for k in range(A.shape[1]):
                total += A[i, k] * B[k, j]
            C[i, j] = total

GPU Reductions

from numba import cuda

# Define reduction operation
sum_reduce = cuda.reduce(lambda a, b: a + b)

# Use it
result = sum_reduce(array)                    # Full reduction
result = sum_reduce(array, init=0)            # With initial value
sum_reduce(array, res=device_result)          # Write to device array (no D→H copy)
sum_reduce(array, stream=stream)              # Async

Custom reduction:

@cuda.reduce
def max_reduce(a, b):
    return a if a > b else b

maximum = max_reduce(data_array)

Streams

Streams enable overlapping computation with data transfer and running multiple kernels concurrently.

stream = cuda.stream()

# Async transfer → kernel → transfer back
d_data = cuda.to_device(host_data, stream=stream)
my_kernel[blocks, threads, stream](d_data, d_out)
result = d_out.copy_to_host(stream=stream)
stream.synchronize()  # Wait for everything on this stream

# Context manager that auto-synchronizes
with stream.auto_synchronize():
    d_data = cuda.to_device(host_data, stream=stream)
    my_kernel[blocks, threads, stream](d_data, d_out)
    result = d_out.copy_to_host(stream=stream)
# Synchronizes here automatically
Pipeline Pattern (overlap transfer and compute)
stream1 = cuda.stream()
stream2 = cuda.stream()

# Chunk 1: transfer on stream1
d_chunk1 = cuda.to_device(data[:half], stream=stream1)
# Chunk 2: transfer on stream2 (overlaps with stream1 transfer)
d_chunk2 = cuda.to_device(data[half:], stream=stream2)

# Process chunk1 on stream1
kernel[blocks, threads, stream1](d_chunk1, d_out1)
# Process chunk2 on stream2 (overlaps with stream1 compute)
kernel[blocks, threads, stream2](d_chunk2, d_out2)

cuda.synchronize()  # Wait for all streams

Random Number Generation

Numba provides GPU-native random number generation using the xoroshiro128+ algorithm.

from numba import cuda
from numba.cuda.random import (
    create_xoroshiro128p_states,
    xoroshiro128p_uniform_float32,
    xoroshiro128p_uniform_float64,
    xoroshiro128p_normal_float32,
    xoroshiro128p_normal_float64,
)

# Create RNG states — one per thread
n_threads = 256 * 128
rng_states = create_xoroshiro128p_states(n_threads, seed=42)

@cuda.jit
def monte_carlo_pi(rng_states, iterations, out):
    gid = cuda.grid(1)
    if gid < out.size:
        inside = 0
        for _ in range(iterations):
            x = xoroshiro128p_uniform_float32(rng_states, gid)
            y = xoroshiro128p_uniform_float32(rng_states, gid)
            if x**2 + y**2 <= 1.0:
                inside += 1
        out[gid] = inside / iterations * 4.0

monte_carlo_pi[128, 256](rng_states, 10000, d_out)

Tip: RNG states consume memory proportional to thread count. Use grid-stride loops to limit the number of states needed for large problems.


Cooperative Groups

For algorithms requiring synchronization across ALL blocks in a grid (not just within a single block).

@cuda.jit
def iterative_kernel(M):
    col = cuda.grid(1)
    g = cuda.cg.this_grid()  # Get grid group

    for row in range(1, M.shape[0]):
        if col < M.shape[1]:
            M[row, col] = M[row - 1, col] + 1
        g.sync()  # Global barrier — all blocks wait here

# Query max grid size for cooperative launch
overload = iterative_kernel.overloads[signature]
max_blocks = overload.max_cooperative_grid_blocks(block_dim)

Cooperative launches are triggered automatically when g.sync() is detected. The grid must not exceed max_cooperative_grid_blocks().


Common Patterns

Tiled Matrix Multiplication with Shared Memory

This is the canonical example of shared memory optimization — tiles of A and B are loaded into fast shared memory to reduce slow global memory accesses.

from numba import cuda, float32
import numpy as np

TPB = 16  # Tile/block size

@cuda.jit
def matmul_shared(A, B, C):
    sA = cuda.shared.array((TPB, TPB), dtype=float32)
    sB = cuda.shared.array((TPB, TPB), dtype=float32)

    x, y = cuda.grid(2)
    tx, ty = cuda.threadIdx.x, cuda.threadIdx.y

    tmp = float32(0.0)
    n_tiles = (A.shape[1] + TPB - 1) // TPB
    for tile in range(n_tiles):
        # Load tile into shared memory (with bounds check)
        col = tx + tile * TPB
        row = ty + tile * TPB
        sA[ty, tx] = A[y, col] if (y < A.shape[0] and col < A.shape[1]) else 0
        sB[ty, tx] = B[row, x] if (x < B.shape[1] and row < B.shape[0]) else 0
        cuda.syncthreads()

        # Compute partial dot product from this tile
        for k in range(TPB):
            tmp += sA[ty, k] * sB[k, tx]
        cuda.syncthreads()

    if y < C.shape[0] and x < C.shape[1]:
        C[y, x] = tmp
Block-Local Inclusive Prefix Sum
@cuda.jit
def block_inclusive_scan(data, output):
    shared = cuda.shared.array(256, dtype=float32)
    tid = cuda.threadIdx.x
    i = cuda.grid(1)

    shared[tid] = data[i] if i < data.size else 0
    cuda.syncthreads()

    # Hillis-Steele scan within one block. Two barriers prevent read/write races.
    offset = 1
    while offset < cuda.blockDim.x:
        addend = float32(0.0)
        if tid >= offset:
            addend = shared[tid - offset]
        cuda.syncthreads()
        if tid >= offset:
            shared[tid] += addend
        cuda.syncthreads()
        offset *= 2

    if i < data.size:
        output[i] = shared[tid]

This computes an independent scan per block, not a whole-array scan. A complete multi-block scan also scans block totals and adds block offsets. Prefer cupy.cumsum()/CUB unless a custom scan operator is required.

Launch block_inclusive_scan with at most 256 threads per block.

Shared Memory Reduction
@cuda.jit
def block_reduce_sum(data, partial_sums):
    shared = cuda.shared.array(256, dtype=float32)
    tid = cuda.threadIdx.x
    i = cuda.grid(1)

    shared[tid] = data[i] if i < data.size else 0.0
    cuda.syncthreads()

    # Tree reduction in shared memory
    s = cuda.blockDim.x // 2
    while s > 0:
        if tid < s:
            shared[tid] += shared[tid + s]
        s //= 2
        cuda.syncthreads()

    # Thread 0 of each block writes the block's sum
    if tid == 0:
        partial_sums[cuda.blockIdx.x] = shared[0]

Launch block_reduce_sum with a power-of-two block size no greater than 256; sum the partial results in a second stage. Other block sizes do not satisfy this reduction algorithm.

Stencil / Neighbor Access Pattern
@cuda.jit
def stencil_1d(data, output, radius):
    shared = cuda.shared.array(288, dtype=float32)  # blockDim + 2*radius
    tid = cuda.threadIdx.x
    i = cuda.grid(1)

    # Load center + halo into shared memory
    shared[tid + radius] = data[i] if i < data.size else 0
    if tid < radius:
        shared[tid] = data[i - radius] if i >= radius else 0
        shared[tid + cuda.blockDim.x + radius] = (
            data[i + cuda.blockDim.x] if i + cuda.blockDim.x < data.size else 0
        )
    cuda.syncthreads()

    if i < data.size:
        total = float32(0.0)
        for j in range(-radius, radius + 1):
            total += shared[tid + radius + j]
        output[i] = total / (2 * radius + 1)

The stencil uses zero padding (a fixed denominator at boundaries). Launch with 256 threads and require 0 <= radius <= 16; larger radii exceed its static shared allocation. Compare that exact boundary convention with the CPU reference.

Performance Optimization

GPU-Specific Tips
  1. Minimize host-device transfers. Use cuda.to_device() and keep data on GPU across multiple kernel calls. Measure on the target system; interconnect and device-memory bandwidth vary widely.

  2. Use shared memory for data reused across threads in a block when profiling shows global memory traffic is limiting performance. Shared memory is finite and can reduce occupancy.

  3. Coalesce memory accesses. Adjacent threads (consecutive threadIdx.x) should access adjacent memory locations. This lets the hardware combine accesses into fewer wide transactions.

  4. Choose block size for occupancy. 128-256 threads/block for 1D, (16,16) or (32,32) for 2D. Too few threads underutilizes the GPU; too many may limit registers/shared memory per thread.

  5. Use fastmath=True when IEEE-754 strictness isn't required. Enables FMA, fast sqrt/division, and faster trig/exp/log for float32.

  6. Prefer float32 over float64 when precision and stability requirements allow. The throughput ratio is architecture-specific, so benchmark the target GPU.

  7. Use streams to overlap data transfer with computation.

  8. Use cuda.defer_cleanup() in performance-critical sections to prevent implicit synchronization from memory deallocation.

  9. Limit register usage with max_registers parameter when occupancy is the bottleneck.

  10. Use grid-stride loops to decouple grid size from problem size and improve flexibility.

What Not To Do
  • Don't use Python objects, strings, or dynamic memory allocation inside kernels — Numba CUDA supports a restricted Python subset.

  • Don't put syncthreads() inside divergent branches — if threads in a block take different paths through a barrier, behavior is undefined (deadlock or corruption).

  • Don't forget cuda.synchronize() before reading results on CPU — kernel launches are async.

  • Don't assume a custom kernel helps small arrays. Measure launch and transfer overhead on the target system and batch or fuse work when overhead dominates.


Debugging

CUDA Simulator

Run CUDA code on CPU for debugging — supports print() and pdb inside kernels.

export NUMBA_ENABLE_CUDASIM=1
python your_script.py

The simulator runs kernels one block at a time, spawning one thread per CUDA thread. Supports shared/local/constant memory, atomics, and syncthreads().

Debug a Specific Thread
@cuda.jit
def debug_kernel(data, out):
    i = cuda.grid(1)
    if cuda.threadIdx.x == 0 and cuda.blockIdx.x == 0:
        # Only thread (0,0) hits the debugger
        from pdb import set_trace; set_trace()
    if i < data.size:
        out[i] = data[i] * 2
On-Device Debug Mode
@cuda.jit(debug=True, opt=False)
def kernel_debug(data):
    # Enables CUDA exception checking — much slower but catches errors
    ...

Interoperability

Numba supports the CUDA Array Interface (version 3) — any object exposing __cuda_array_interface__ can be passed directly to Numba kernels with zero copy.

With CuPy
import cupy as cp
from numba import cuda

@cuda.jit
def add_kernel(x, y, out):
    i = cuda.grid(1)
    if i < x.shape[0]:
        out[i] = x[i] + y[i]

# CuPy arrays work directly — zero copy
a = cp.arange(1000, dtype=cp.float32)
b = cp.ones(1000, dtype=cp.float32)
out = cp.zeros(1000, dtype=cp.float32)
add_kernel[4, 256](a, b, out)
With PyTorch
import torch
from numba import cuda

t = torch.tensor([1, 2, 3], dtype=torch.float32, device="cuda")
d_array = cuda.as_cuda_array(t)  # Zero-copy Numba view of PyTorch tensor
Checking GPU Arrays
cuda.is_cuda_array(obj)       # True if obj has __cuda_array_interface__
cuda.as_cuda_array(obj)       # Wrap as Numba device array (zero copy)

Compatibility is object-specific: check cuda.is_cuda_array(obj). Convert JAX or TensorFlow through a supported DLPack consumer such as CuPy instead of assuming every tensor exposes this interface.


Common Pitfalls

  1. Forgetting bounds checks. If blocks * threads > array_size, out-of-bounds threads corrupt memory silently. Always: if i < array.size.

  2. Trying to return values from kernels. Kernels cannot return — write to output arrays instead. Return values are silently discarded.

  3. Implicit synchronous transfers. Passing host (NumPy) arrays directly to kernels triggers synchronous copy-back. Use explicit cuda.to_device() / copy_to_host().

  4. Shared memory size must be a compile-time constant for static allocation. Use dynamic shared memory (size=0) for runtime-determined sizes.

  5. Dynamic shared memory aliasing. All cuda.shared.array(0, ...) in the same kernel share the same memory. Slice manually for multiple arrays.

  6. syncthreads() in divergent branches. All threads in a block must reach the same syncthreads() call. Divergent paths → undefined behavior.

  7. Atomic operation type restrictions. atomic.add supports int32, float32, float64. Bitwise atomics only work on integer types.

  8. Forgetting cuda.synchronize(). Kernel launches are async. Reading host-side results before sync gives stale/incomplete data.

  9. Unsupported Python features in kernels. No dynamic allocation, no Python objects, no string operations, no exceptions (unless debug mode). Stick to numeric types and math.

  10. Using float64 on consumer GPUs. Consumer NVIDIA GPUs (GeForce) have heavily throttled float64 throughput (often 1/32 of float32). Use float32 unless you need the precision.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs network access, Needs Python

The author says: Requires an NVIDIA CUDA-capable GPU for GPU execution. RAPIDS 26.08 requires Python 3.11-3.14 on Linux or WSL2, NumPy 2, CuPy 14, and compatible CUDA 12 or 13 wheels. Package installation needs network access.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
K-Dense, Inc.
Publisher
K-Dense (Community)
Source
K-Dense-AI/scientific-agent-skills · skills/optimize-for-gpu · commit a25cf9e
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE.md)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by K-Dense, Inc. or K-Dense.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download optimize-for-gpu.zip