Skip benchmarking single pruned autotune configs by yinli-systems · Pull Request #10413 · triton-lang/triton

yinli-systems · 2026-05-29T16:04:59Z

When prune_configs_by reduces a multi-config autotune set to one config, the autotuner currently still benchmarks that single option. This makes the pruned-single case slower than an explicit single-config autotune even though there is no choice left to tune.

This change:

directly selects the only pruned config without benchmarking it
keeps autotune listener behavior aligned with explicit single-config autotune, where no benchmark event is emitted
adds regression coverage for both early_config_prune and perf_model/top_k=1 paths

Local checks:

python3 -m compileall -q python/triton/runtime/autotuner.py python/test/unit/runtime/test_autotuner.py
git diff --check

Not run locally:

PYTHONPATH=python python3 -m pytest -q python/test/unit/runtime/test_autotuner.py::test_pruned_single_config_skips_benchmark because this checkout does not have a built triton._C.libtriton extension.

…ds to zero (#10689) ## Summary `Autotuner.prune_configs` treats a float `top_k <= 1.0` as a fraction of the configs: ```python if isinstance(top_k, float) and top_k <= 1.0: top_k = int(len(self.configs) * top_k) ``` For a small config set a small fraction rounds down to zero — e.g. `int(2 * 0.3) == 0`. The perf-model branch then slices `sorted(est_timing.keys(), ...)[:0]` and returns an **empty** config list. Back in `run()` the benchmark path builds an empty `timings` dict and `min(timings, key=timings.get)` raises `ValueError: min() arg is an empty sequence`. `top_k` (including the fractional form, type-checked at the same spot) is a documented `prune_configs_by` field, and `early_config_prune` already guarantees "at least one config" — but the fractional `top_k` path doesn't. ## Fix `max(1, int(len(self.configs) * top_k))` — always keep at least the single best config, matching the `early_config_prune` guarantee. Normal fractions and integer `top_k` are unaffected (`int(5 * 0.5) == 2`; an integer `top_k` skips this branch). When it resolves to a single config, the existing single-pruned-config fast path (#10413) takes over and skips benchmarking. ## Test Added `test_prune_configs_fractional_top_k_keeps_one`, mirroring `test_prune_configs`: two configs + a perf model + `top_k=0.3` (which truncates to 0). Before the fix the autotuned launch raises the empty-`min()` `ValueError`; after it the best config is kept and the kernel runs. ## Verification I verified the truncation logic and the `max(1, ...)` fix standalone in pure Python (`int(2 * 0.3) == 0` → empty slice → crash; `max(1, 0) == 1` → one config kept). I wasn't able to run the unit test locally — no GPU, and the Triton C extension isn't built on my machine — so the added test relies on CI. The change is `ruff` and `yapf` clean.

Fixes triton-lang#9821. When `prune_configs_by` reduces a multi-config autotune set to one config, the autotuner currently still benchmarks that single option. This makes the pruned-single case slower than an explicit single-config autotune even though there is no choice left to tune. This change: - directly selects the only pruned config without benchmarking it - keeps autotune listener behavior aligned with explicit single-config autotune, where no benchmark event is emitted - adds regression coverage for both `early_config_prune` and `perf_model`/`top_k=1` paths Local checks: - `python3 -m compileall -q python/triton/runtime/autotuner.py python/test/unit/runtime/test_autotuner.py` - `git diff --check` Not run locally: - `PYTHONPATH=python python3 -m pytest -q python/test/unit/runtime/test_autotuner.py::test_pruned_single_config_skips_benchmark` because this checkout does not have a built `triton._C.libtriton` extension. --------- Co-authored-by: Kevin-Li-2025 <2242139@qq.com>

…ds to zero (triton-lang#10689) ## Summary `Autotuner.prune_configs` treats a float `top_k <= 1.0` as a fraction of the configs: ```python if isinstance(top_k, float) and top_k <= 1.0: top_k = int(len(self.configs) * top_k) ``` For a small config set a small fraction rounds down to zero — e.g. `int(2 * 0.3) == 0`. The perf-model branch then slices `sorted(est_timing.keys(), ...)[:0]` and returns an **empty** config list. Back in `run()` the benchmark path builds an empty `timings` dict and `min(timings, key=timings.get)` raises `ValueError: min() arg is an empty sequence`. `top_k` (including the fractional form, type-checked at the same spot) is a documented `prune_configs_by` field, and `early_config_prune` already guarantees "at least one config" — but the fractional `top_k` path doesn't. ## Fix `max(1, int(len(self.configs) * top_k))` — always keep at least the single best config, matching the `early_config_prune` guarantee. Normal fractions and integer `top_k` are unaffected (`int(5 * 0.5) == 2`; an integer `top_k` skips this branch). When it resolves to a single config, the existing single-pruned-config fast path (triton-lang#10413) takes over and skips benchmarking. ## Test Added `test_prune_configs_fractional_top_k_keeps_one`, mirroring `test_prune_configs`: two configs + a perf model + `top_k=0.3` (which truncates to 0). Before the fix the autotuned launch raises the empty-`min()` `ValueError`; after it the best config is kept and the kernel runs. ## Verification I verified the truncation logic and the `max(1, ...)` fix standalone in pure Python (`int(2 * 0.3) == 0` → empty slice → crash; `max(1, 0) == 1` → one config kept). I wasn't able to run the unit test locally — no GPU, and the Triton C extension isn't built on my machine — so the added test relies on CI. The change is `ruff` and `yapf` clean.

…e configs (#10413)' Summary: This is a backport of an upstream PR: triton-lang/triton#10413 Upstream commit message: ``` > Skip benchmarking single pruned autotune configs (#10413) > Fixes #9821. > When `prune_configs_by` reduces a multi-config autotune set to one > config, the autotuner currently still benchmarks that single option. > This makes the pruned-single case slower than an explicit single-config > autotune even though there is no choice left to tune. > This change: > - directly selects the only pruned config without benchmarking it > - keeps autotune listener behavior aligned with explicit single-config > autotune, where no benchmark event is emitted > - adds regression coverage for both `early_config_prune` and > `perf_model`/`top_k=1` paths > Local checks: > - `python3 -m compileall -q python/triton/runtime/autotuner.py > python/test/unit/runtime/test_autotuner.py` > - `git diff --check` > Not run locally: > - `PYTHONPATH=python python3 -m pytest -q > python/test/unit/runtime/test_autotuner.py::test_pruned_single_config_skips_benchmark` > because this checkout does not have a built `triton._C.libtriton` > extension. > --------- > Co-authored-by: Kevin-Li-2025 <2242139@qq.com> ``` ***Do not remove the following line from this commit*** Reactor Backport Revision: be7158e --- This diff was generated by running: ``` buck run fbcode//triton/tools/reactor:reactor -- backport --pr 10413 ``` Differential Revision: D114490246

…e configs (#10413)' (facebookexperimental#2692) Summary: Pull Request resolved: facebookexperimental#2692 This is a backport of an upstream PR: triton-lang/triton#10413 Upstream commit message: ``` > Skip benchmarking single pruned autotune configs (#10413) > Fixes #9821. > When `prune_configs_by` reduces a multi-config autotune set to one > config, the autotuner currently still benchmarks that single option. > This makes the pruned-single case slower than an explicit single-config > autotune even though there is no choice left to tune. > This change: > - directly selects the only pruned config without benchmarking it > - keeps autotune listener behavior aligned with explicit single-config > autotune, where no benchmark event is emitted > - adds regression coverage for both `early_config_prune` and > `perf_model`/`top_k=1` paths > Local checks: > - `python3 -m compileall -q python/triton/runtime/autotuner.py > python/test/unit/runtime/test_autotuner.py` > - `git diff --check` > Not run locally: > - `PYTHONPATH=python python3 -m pytest -q > python/test/unit/runtime/test_autotuner.py::test_pruned_single_config_skips_benchmark` > because this checkout does not have a built `triton._C.libtriton` > extension. > --------- > Co-authored-by: Kevin-Li-2025 <2242139@qq.com> ``` ***Do not remove the following line from this commit*** Reactor Backport Revision: be7158e --- This diff was generated by running: ``` buck run fbcode//triton/tools/reactor:reactor -- backport --pr 10413 ``` Differential Revision: D114490246