Searching the Parameter Space

Every combination of your knobs forms the parameter space. Searching it means trying combinations and finding which one runs fastest.

First list the values each knob may take. The set of all pairings of tile and width gives the candidates to evaluate.

For every combination, the compiler builds a specialized version of the kernel with those exact parameter values baked in.

Run each candidate on a representative input and record how long it takes. Honest timing is what makes the comparison meaningful.

Discard the first few runs as warm-up. Caches and the CPU settle in, so early timings are noisy and not representative.

Time each candidate several times and take the best or median. Repetition smooths out random noise from the operating system.

Feed every candidate the same input and the same workload size, so the only thing that varies is the configuration under test.

The candidate with the lowest time becomes the winner. That parameter set is the one your code should specialize on.

A small space allows a full grid search of every combination. A large one may need sampling so tuning does not take forever.

The search happens once, ahead of deployment. You pay tuning time now to enjoy faster runs for every execution afterward.

Save the winning values so you can reuse them. A logged result means you do not repeat the whole search next time.

Recall how a candidate is chosen during the search.

You enumerated candidates, built and timed each on a fair workload, smoothed out noise, and picked the fastest configuration as the winner. 🎯