Autotuning pays for every candidate

Define configurable choices and reject combinations that violate dependency, memory, alignment, target, or numeric contracts. A schedule that silently enables broader fast-math permissions is not directly comparable with a strict reference unless the product explicitly accepts that changed contract. Check output correctness and memory safety before recording performance as a useful candidate. Compilation success alone does not show that tail handling, aliasing, or synchronization is correct on all valid inputs.

The Cartesian product of choices can grow quickly, but not every combination is independent or supported. A vector width may constrain tile shape, a pipeline depth may exceed shared-memory capacity, and a layout may preclude a library path. Prune with justified constraints rather than using the cost model to explain away illegal results. Preserve the exact target, compiler revision, flags, and generated configuration so the winner can be reproduced rather than remembered as one unexplained benchmark number.

A heuristic or learned model can rank candidates cheaply using features such as operation shape, resource use, and target properties. Its prediction is not a legality proof or a throughput guarantee. Training on one device, compiler, or workload distribution can make rankings poor after a target change. Keep held-out shapes and realistic contention conditions, and compare prediction errors with actual useful latency. A model can still help if it reliably places good candidates near the top, even without exact time predictions.

Measurements themselves are noisy. Warmup, compilation, cache state, synchronization, clocks, thermal behavior, and competing jobs can change results. Time the relevant completion boundary and repeat candidates under a consistent policy. The minimum of many noisy measurements is biased toward lucky outcomes; retest finalists independently. Include setup and conversion costs when production pays them. A kernel-only winner that requires an expensive per-call layout conversion may lose in the complete graph.

Key cached tuning results by the properties that affect validity and performance, including shapes, dtype, relevant layout, target, compiler revision, and numeric mode. A result for one alignment or dynamic range may not transfer to another. Bound tuning at startup or provide a safe baseline so a cold service does not stall on a large search. Revalidate after backend upgrades and preserve correctness checks for the selected configuration, particularly when previously pruned or unsupported schedules become available.

The optimization lab provides only a contrasting smooth problem. Reset and set both step size η=0.5 and initial position x₀=2, predict that the first gradient-descent update on f(x)=x²/2 gives x=1, then inspect as the iteration advances with Play or Step. It has no schedules, compiler, resource constraints, or measured kernels. Real tuning spaces are discrete and can be irregular, so this toy's convergence does not justify assuming a smooth convex landscape or following its updates as a compiler search algorithm.