gale-gpu-perf

Enforce GPU performance discipline with ncu, nsys, and nvidia-smi profiling.

1|Updated May 29, 2026
One-click install
npx skills add https://github.com/ianrgraham/gale --skill gale-gpu-perf
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: gale-gpu-perf
Source: https://github.com/ianrgraham/gale/tree/main/.claude/skills/gale-gpu-perf
Command: npx skills add https://github.com/ianrgraham/gale --skill gale-gpu-perf

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents GPU changes in gale-gpu from becoming correct-but-slow by enforcing device residency, persistent handles, and mandatory profiling before the work is considered done.

Core Features & Use Cases

  • Performance Discipline: Catches one-shot kernel loads, per-step host-device ping-pong, and other GPU utilization killers.
  • Production Readiness: Verifies that simulation state stays on the device and that time stepping is driven without unnecessary host synchronization.
  • Profiling Gate: Requires real measurements with nsys, ncu, and nvidia-smi so kernel changes are judged by wall-clock behavior, not assumptions.
  • Use Case: When a CUDA kernel, launch wrapper, or GPU integrator path changes, use this Skill to confirm the code is fast, resident, and sweep-ready.

Quick Start

Use this skill whenever you modify GPU code in gale-gpu and report the profiling results before declaring the change complete.

Frequently Asked Questions about gale-gpu-perf

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent CUDA kernels from slowing down due to host-device synchronization?

Profiling GPU code with nsys, ncu, and nvidia-smi validates kernel performance by measuring actual wall-clock behavior. This profiling gate ensures CUDA modifications are judged by real execution metrics rather than assumptions, preventing correct-but-slow code.

What is device residency in GPU simulation paths and when is it required?

Device residency in GPU simulation paths means keeping simulation state on the GPU and driving time stepping without host synchronization. It is required for production-ready CUDA kernels and integrator paths that must remain fast and fully device-resident during execution.

How do I profile modified CUDA launch wrappers before marking work complete?

Profile modified CUDA launch wrappers by running nsys, ncu, and nvidia-smi to capture real performance metrics. You must report these profiling results and verify the absence of per-step synchronization before declaring the kernel change complete.

Does this GPU performance discipline approach work with Rust-based CUDA integrators?

Yes, this GPU performance discipline applies to Rust-based CUDA integrators and host launch wrappers. It enforces persistent handles and device residency while requiring ncu and nsys validation to ensure Rust GPU code remains fast and sweep-ready.

Why does my GPU code pass correctness checks but run slowly during time stepping?

GPU code runs slowly during time stepping if it uses one-shot kernel loads or per-step host-device synchronization. Enforcing device residency and persistent handles eliminates these GPU utilization killers, ensuring simulation state stays on the device.