Writing high-performance GPU kernels should be a tight developer loop: edit, run, measure, repeat. In Helion, a Python DSL that lowers to Triton, that loop is often dominated by autotuning. Full random search could find excellent kernels, but it often took 10 to 20 minutes per compile. A strategy that starts from a default kernel configuration finished in seconds, but produced kernels 14-31% slower. Worse, the autotune cache was tied too closely to source identity: rename a variable, move code around, or change a comment, and prior tuning work could be lost.

This talk presents FROM_BEST_AVAILABLE, a warm-start strategy I contributed to Helion - now the default for quick autotuning - that seeds search from configurations previously tuned for the same input characteristics and device, even when the kernel source has changed. Instead of forcing developers to choose between “slow but good” and “fast but worse,” it reuses prior tuning work to start from a promising neighborhood while still allowing the autotuner to search.

This reduced MatMul autotuning time from 1238 seconds to 92 seconds while matching full-search quality across the seven kernels we benchmarked. I’ll cover how the loose-match key was designed, the trade-offs behind it, and concrete examples of how this approach can improve developer iteration without sacrificing kernel quality.