GPU-Solver

A GPU-kernel optimization loop whose classification rule table evolves from measurement feedback — a rule that keeps failing is retired by measurement, not by an LLM's judgment call.

6.4×
matmul gain (fp32 → TF32, A100)
5.75×
evolution ON vs OFF, endpoint
0
cases evolution made things worse
Architecture: generate, gate, profile, match, ledger, evolve loop; orange feedback edges from evolve back into the rule table

One round = generate → gate → profile → match → ledger → evolve. The orange edges feeding back into rules are the feedback edge static-rule prior art doesn't have.

Try it: evolution ON vs OFF

Same variant pool, same problem (kb_matmul_scalar, real A100 run). Only the evolver differs.

Evolution ON — rule table updates from measurement
RoundRule firedSignalOutcome
Best latency: 55.5 µs — misfire retired at round 4, uncoalesced fired next (load_eff 41.7% measured), tensor cores excluded (FFMA).

Gain axis — matmul 6.4×

measure → hypothesize → rewrite → faster kernel (A100)

matmul fp32 9.6ms to TF32 1.5ms, 6.4x speedup

fp32 ampere_sgemm 9.6 ms → TF32 cutlass_tensorop 1.5 ms = 6.4×. Kernel name changed (sgemm ≠ tensorop) — a genuinely different kernel was selected, not a flag flip. Same contract on batched GEMM: 4.5× (2631 → 580 µs).

Endpoint — evolution ON beats OFF

retire opens the path to gain — reproduced 3× (5.82× / 5.78× / 5.75×)

evolution ON best 55.5us vs OFF best 319.1us, 5.75x, kb_matmul_scalar

Evolution OFF stays trapped on a misfiring rule forever: 319.1 µs. Evolution ON: failures accumulate → retire → next eligible rule fires → 55.5 µs = 5.75×. Same callback, same variant pool — the only difference is the evolver.

Rule retirement — the mechanism itself

evolution ON retires the false rule at round 4; OFF never retires (T4, 8 rounds)

evolution ON retires the false rule at round 4 (retire=1); OFF never retires (retire=0); latency flat on both

Latency is flat on both tracks (T4 fp32 ceiling) — the difference is the retire itself, not speed. This is the step static-rule prior art structurally cannot do.

Limits / not proven

  • Sample size is small. The natural multi-problem batch is 4 problems (1 headroom + 3 bandwidth-ceiling). The batch driver already scales to KernelBench's 250-problem set — running it is seed-wrapping work, not new mechanism, and has not been done.
  • "Both axes as one event" is not claimed. Retire (rule A's event) and gain (rule B's event) are sequential by construction. What's proven is the endpoint of the causal chain, not simultaneity.
  • No SOTA performance claim. The differentiator is interpretable, auditable, evolving judgment — orthogonal to absolute kernel performance.
  • "Reproduced 3 runs" means the same procedure re-run 3 times, not verification by an isolated second party from raw artifacts alone.
  • Rule-firing correctness has not been adversarially tested against out-of-distribution kernels.