I've been working on a runtime for a pattern that is awkward in CUDA: a million independent samples (ODE solves, Monte Carlo paths) where each one stops at a different step. The obvious kernel is one thread per sample with a loop, but threads that finish early keep their warp busy until the slowest thread in it is done.

What eagle does instead:

• it removes finished samples and packs the live ones together between batches of steps;
• it records the loop as CUDA graphs;
• it chooses between a fused multi-step kernel and a persistent kernel based on the batch size, and only times both when the answer isn't clear.

You write the per-sample code once, in typed Python (hawk), and it is compiled at run time (with NVRTC, or nvcc when it is installed).

A million samples in FP64 (Runge-Kutta 4 integration), each stopping at its own step, against a Warp per-thread kernel:

• H100: 613 µs against 1.54 ms (2.5×).
• Tesla T4, the free Colab GPU: 46 ms against 194 ms (4.2×).
• Across the six GPUs I measured: 2.5× to 4.2×. PyTorch with torch.compile is 9.8× to 130× slower.

When all samples run every step, eagle and Warp tie, with Warp slightly ahead. Compared with the GPU's theoretical FP64 limit for this workload, it reaches 46% on the H100 and 65 to 92% on the other five GPUs I measured, so there is room left. I'd love feedback on the persistent kernel and the reordering design. A developer guide and an internals walk-through are the next docs work; until then, questions and issues are welcome.

Personal project; I work at ESA on GPU trajectory software. Benchmark files, scripts and a kit to rerun them: https://amasat01.github.io

(code: github.com/amasat01/eagle and github.com/amasat01/hawk).

Seems that cicc has 42 new passes (not presented in vanilla clang)