This is a reminder issue ...
During histogram tuning (islands-era), some variants were recorded with timings that belonged to the previously built variant. Verifying the "winners" then showed 3–14× slowdowns at exactly the cells where the search claimed wins.
Every variant is rebuilt into the same .variant binary. The builds table shows two populations of successful builds: real ones (~5 s) and no-op ones (~0.5 s). When a variant's first build is a no-op, no binary for it ever existed - the run stage executed whatever binary the last real build left behind, and the results were stored under the new variant's name.
I am not sure why this didn't show up before. Opening issue to remember to investigate.
This can be closed when
we verify that if a variant build produces no fresh binary, it's being treated as failed and stores nothing on our new mgpu search path.
This is a reminder issue ...
During histogram tuning (islands-era), some variants were recorded with timings that belonged to the previously built variant. Verifying the "winners" then showed 3–14× slowdowns at exactly the cells where the search claimed wins.
Every variant is rebuilt into the same .variant binary. The builds table shows two populations of successful builds: real ones (~5 s) and no-op ones (~0.5 s). When a variant's first build is a no-op, no binary for it ever existed - the run stage executed whatever binary the last real build left behind, and the results were stored under the new variant's name.
I am not sure why this didn't show up before. Opening issue to remember to investigate.
This can be closed when
we verify that if a variant build produces no fresh binary, it's being treated as failed and stores nothing on our new mgpu search path.