Three axes of advantage: what wins, when, and where
A runtime that claims to beat classical methods invites one fair question: beat them at what? The honest answer is that Stateful Wave Computing wins on three separate axes, and confusing them is the fastest way to make a real result look like a loss.
The same number, measured three ways
“Faster” is not a measurement. Before any benchmark means anything, you have to name the axis it lives on — wall-clock time, total measurements, solution quality, energy per decision. A method can dominate on one axis and lose on another against the very same baseline, and both results are true. Most arguments about optimizers are really arguments about which axis matters, conducted without anyone saying so.
We hold ourselves to naming the axis every time. There are three where the runtime has a real, bounded advantage, and they are genuinely different claims.
Axis one: measurements per update
This is the structural one, and it is not a tuning result — it is a property of the algorithm. To make a single update step, the runtime reads the system once. A finite-difference gradient reads it n+1 times; it has to perturb every coordinate to estimate a slope. So the measurement-efficiency gap grows linearly and without bound: at a thousand parameters it is a thousandfold, at four thousand it is four-thousandfold. In regulation, this is why tracking quality stays essentially flat as the channel count climbs three orders of magnitude while a gradient baseline saturates and stops tracking at all. Nothing about this depends on the problem being easy. It is the shape of the update.
Axis two: solution quality before a deadline
This one rests on a premise we state out loud: that a configuration measurement is parallel and roughly constant-cost in n, because the substrate evolves the whole vector at once. Grant that, and a different picture emerges under a fixed wall-clock deadline. A sequential classical solver pays per move, so as the problem grows it completes fewer useful moves inside the same clock — it starves. The runtime’s round count does not shrink with dimension. Past a crossover near a thousand variables, it overtakes, and the margin widens with size: at a few thousand variables in a millisecond budget, sequential search is reduced to near-guesswork while the runtime still returns a usable answer. Tighten the deadline and the crossover moves to smaller problems.
Below the crossover, a classical solver wins, and we say so. This is the real-time-at-the-edge corner — large problems, hard deadlines — not a claim about generous budgets.
Axis three: total measurements to a quality bar
The newest result concerns how the total measurement count grows with problem size when you hold the target quality fixed. A score-weighted estimator — weighting a sliding window of recent samples by how well they scored, rather than keeping only the best — reaches a usable solution in about n1.2 total measurements on structured problems, where the older best-sample rule scales closer to n2. On dense, fully-coupled problems the exponent rises toward n1.5 — still sub-quadratic, but the gain tracks structure. This is the runtime improving against its own prior law. Against a well-run classical annealer at equal measurement budget, it is competitive, not superior — the win over classical search lives on axis two, the deadline.
Why the distinction is the product
If you test equal-budget solution quality on a small problem, the runtime will not beat a good annealer — and nothing we publish claims it should. That is axis three on a size below axis two’s crossover, the one corner where no result claims a win. Keeping the axes straight is not a disclaimer; it is what lets every individual claim be sharp and survivable. A buyer who knows exactly which axis they live on knows exactly whether this runtime helps them. You can reproduce all three on your own hardware from the reproduce page.