Docs

Baselines: where it wins

The runtime wins in specific, stateable conditions — not everywhere. This page maps it against each classical baseline across budget regimes, from benchmarks against fairly-tuned methods. Every cell is a regime, not a slogan: where the runtime leads, where a baseline leads, and the condition that flips it. We state the losses as plainly as the wins.

The one-line summary per baseline

BaselineWhere the runtime winsWhere the baseline wins
Gradient / SPSA / finite-differenceEvery tight-budget regime, at all sizes — and the margin is large. These methods must spend measurements estimating a direction; under a tight budget at high dimension they cannot assemble a step and stall. In benchmarks at n=256 under a starved budget the runtime reaches ~0.52 recovery where SPSA reaches ~0.14.When measurements are abundant and the objective is smooth and stationary, a well-tuned gradient method is fine. If your current loop already converges comfortably, keep it — the client says so.
Simulated annealing (SA)The starved-budget regime at scale. When a classical solver gets too few evaluations per variable to search (≈ 1–2 per variable) it stalls at a fixed quality floor regardless of dimension; the runtime keeps improving as the problem grows and overtakes SA past a crossover (≈ n=256–512 in benchmarks), the margin widening with size.Given an ample budget (≥ ~5 evaluations per variable), SA remains competitive and often edges the runtime on final solution quality. We say so plainly. SA is a strong classical optimizer; the runtime's edge over it is the starved regime, not a universal win.
Random / equal-sample searchEverywhere it matters. The runtime reaches a usable solution while equal-sample random search stays near the noise floor (≈ 0.19–0.26 at n=256 across budgets). The substrate-as-optimizer beats equal-sample random search by an order of magnitude in benchmarks.On trivially small instances random search can be competitive simply because the space is tiny. The advantage appears and grows with dimension.
Best-tuned PI controller (regulation)Nonlinear and sign-varying plants under drift. The runtime re-estimates each channel's local sensitivity from measurement every round, tracking 2–4× tighter than a gains-swept PI on nonlinear plants, and the margin grows with how nonlinear the plant is.On a linear, stationary, well-characterized plant a tuned PI is excellent and simpler. The runtime is for plants that move, are nonlinear, or whose polarity is unknown.

The numbers: recovery by regime at n=256

Mean recovery (fraction of the achievable optimum), coupled QUBO at n=256, 8 seeds, identical total measurement budget per column. The budget is expressed as evaluations per variable. SWC uses the score-weighted estimator. This single experiment is the source for the cells above.

Budget regimeSWCSASPSARandom
Starved (1 / variable)0.520.540.140.19
Tight (8 / variable)0.940.960.150.23
Ample (40 / variable)0.961.000.160.26

Read it honestly: against SPSA and random search the runtime dominates in every regime. Against SA at a single size it is close and SA edges it given budget — the runtime’s win over SA is a scaling effect that appears at larger n under starvation, shown next.

Where the runtime passes SA: the starved-budget crossover

At exactly 1 evaluation per variable (a starved budget held as a fixed ratio), SA stalls — its quality flat regardless of dimension — while the runtime’s quality climbs with dimension and overtakes it. 12 seeds, coupled QUBO, bootstrap-significant past the crossover.

nSWCSAMargin
1280.450.53−0.08
2560.520.54−0.02
5120.580.54+0.05
10240.640.54+0.10

SA is flat (~0.54) across an 8× increase in dimension — it is out of budget to search. The runtime climbs from 0.45 to 0.64 and passes SA near n=512, the margin widening from there. This is the precise, defensible form of “the advantage grows with dimension” in optimization: it holds against a stalled classical solver under a starved budget, and we do not claim it outside that regime.

Honest scope: absolute quality at 1 evaluation per variable is modest for everyone (~0.6) — the runtime degrades gracefully under starvation, it does not solve the instance well. Give any method an ample budget and the picture changes. All figures are from controlled benchmarks against fairly-tuned baselines; on-chip validation is in progress. Your own numbers are one demo run away — drop the client into your loop and measure it on your problem.