Compiler-Thermal
A compiler-optimization loop that judges GPU kernel transformations by simulated hotspot ΔT (K) from an RC thermal model, not latency or raw energy — the same measurement-driven rule engine as the sibling latency-axis project, with the objective swapped.
rules.py, evolver.py, ledger.py are unchanged from
gpu-solver-loop — only harness._metric(mode="thermal") changed, from -latency
to -energy_per_iter_j. A second, independent axis converts the same measured power into
a hotspot ΔT (K) via a two-node RC model, cross-checked against Ansys Twin Builder.
Try it: move the duty cycle
Same matmul measurement (fp32 → TF32, A100), same RC model — only the assumed
duty cycle changes. Points below are the RC model evaluated directly at each duty value
(thermal_loop/report_p4_deltat.py::_scenario_b), not a fitted or hand-drawn curve.
Energy axis — TF32 vs fp32, 5.32×–5.75×
two independent replicate runs of the same round-0→round-1 sequence (evolution OFF / ON), matmul, A100
Same two-round sequence run twice (OFF/ON refer to the evolver, not two different kernels) — gain is computed within each replicate, not across them. 5.32× and 5.75×, both real A100 measurements. This is the input the 17.16 K hotspot number above is derived from.
Ablation — compute-matmul bucket, 2.61×–6.00×
KernelBench-derived 35-problem stratified sample, v3 pre-registered criterion
7 of 8 compute-matmul problems show a real, non-null TF32 energy gain (bucket reclassification, v4); at the original pre-registered criterion across all compute-bound buckets, v3 reproduction is 40% — reported alongside, not replaced. Memory-bound problems correctly show 100% null (no false gain claimed).
Prior art — judged quantity × feedback loop
6-system survey; no prior system couples a compiler decision to a simulated physical temperature
| System | Judged quantity | Rule/decision feedback loop |
|---|---|---|
| Zhang et al. 2024 (energy-aware kernel gen) | Energy (J) | No — static cost model |
| KernelPro | Latency, energy (tiebreak) | No — LLM-judged classification |
| FlipFlop | Power/energy (static estimate) | No — static analysis |
| Zeus | Energy (J), via NVML | No — power-cap tuning |
| GPOEO | Energy, DVFS setpoint | No — online frequency search |
| LPTN / Twin Builder thermal-ROM | Temperature (°C) | N/A — never coupled to a compiler loop |
| This project | Simulated hotspot ΔT (K), via RC model | Yes — same rule/evolver/ledger as gpu-solver-loop |
Full survey and citations: README §2.
Limits / not proven
- No physical measurement — simulation vs. simulation. Every ΔT and energy figure comes from measured GPU power/traffic signals fed through a compact RC thermal model, cross-checked against Ansys Twin Builder simulation output. No thermocouple or die-shot ground truth anywhere in this chain.
- The iso-work duty cycle (15.66%) is a chosen comparison basis, not the only valid one, and it is load-bearing — the slider above makes that adjustable by hand rather than asserting it in a footnote.
- KernelBench ablation is 40% at the pre-registered criterion. The 87.5%/7-of-8 figure is a bucket reclassification of the same v3 results, not a re-measurement.
- Hotspot amplification (1.23×–1.64×) contradicts the pre-registered expectation (attenuation was hypothesized going in) — reported as observed, at both a 16 W and an independent 30 W condition, not adjusted to fit the hypothesis.
- No claim of identical methodology across all three sibling repos. This repo and hbm-build document pre-registered hypotheses with recorded reversals and sha256-checked reproducibility; gpu-solver-loop does not have documented evidence of either practice.
- Independent verification here means re-derivation from raw ledger files by a separate reviewing pass within this project, not an external, disinterested third party.