Benchmarks

The machine

The host is shared with other users, so every timed run waited for it to go quiet first (Method). Three definitions hold on the whole page:

• One core: one single-threaded process pinned to one physical core (CPU 20) with that core's second hardware thread (CPU 44) idle. The shipped game runs several threads per process, so for it one core means one game process and its Python driver confined to both hardware threads of that core.
• Both threads of one core: two of our processes on CPUs 20 and 44. For the game: 2 to 16 game processes sharing CPUs 20 and 44.
• Whole machine: all 24 cores and 48 threads. For a Rust engine, the better of 24 processes (one per core) and 48 (one per hardware thread); for the game, the best of 24 to 384 processes. Each table says which one won.

An action is one state transition: a card play or an end of turn. Whole-machine rates are the sum of the processes' own rates, all released at the same instant.

Engine throughput

The workload is random play: Ironclad at Ascension 0, the 10-card starter deck at 80/80 HP and Burning Blood, against the 22 Act-1 Overgrowth encounters in turn (4 weak, 12 normal, 3 elites, 3 bosses), with uniformly random legal moves until the fight ends. Each fight starts from a copy of a start state built the way a real run builds it. A run is 110,000 fights: 2,200 seeds × 50. The random player wins 32.4% of them, with 22.0 actions per fight.

The new engine is 2.25× faster (median of 7 interleaved pairs; 2.17–2.37×). It executes half the instructions per action (the previous one needs 2.08×) and the fights are identical: the same 2,417,920 actions, the same 35,646 wins and the same digest over every fight's length and outcome in all 14 runs.

Each process plays 440,000 fights. Efficiency = the aggregate rate ÷ (processes × the same repeat's one-process rate), so a value near 0.5 on the two-thread presets means each core still does about the work of one process. Every process of every preset played identical fights (one digest).

Measured the same way, the previous engine reaches 13.8 M actions/s on the whole machine (48 processes), so the new one is 2.24× faster there as well (2.23× on one core of the same series). With every core busy the clock falls from 3.91 to 3.79 GHz (24 processes) and 3.65 GHz (48), which accounts for most of the missing 5% at 24 processes.

Against the shipped game

What "headless" means. The game's own assembly, sts2.dll of build v0.107.1 from a copy of the game, IL-patched and run by the project's harness on .NET 9 with Godot stubbed out: no window, no rendering, no animations. A Python driver talks to it as JSON over a pipe and plays the same fights as the Rust benchmark, choosing uniformly at random from the game's own list of legal actions. It is the same oracle the parity suite checks the engine against. Random play gives the same statistics on both: over 8,448 fights the game wins 32.2% with 21.98 actions per fight, our engine 32.4% with 21.98 over 110,000, and 21 of the 22 encounters agree within two standard errors (largest |z| 2.05).

Why one game process is mostly asleep. After every card play the harness waits for the game's action queue to drain by polling it: Thread.Sleep(1) until five idle checks in a row (WaitForActionExecutor in sts2-pycli/src/Sts2Headless/RunSimulator.cs). The game thread goes to sleep 8.6 times per action, and a warm game process is on the CPU for only 22% of its play time: 2.28 ms of CPU in 10.4 ms per action. The wall time of one process therefore measures the harness's sleeping as much as the game. The fair comparisons are CPU time and throughput with many game processes sharing the CPUs, as many as raised the game's throughput in the layouts tried.

The fair headline: against the game's best measured process count (16 on one core, 192 on the machine), our engine does about 1,500 times the shipped game's work on one core and 2,430 times on the whole machine. Per unit of CPU time it is 2,250 to 2,970 times in one warm game process (game thread or whole process), and 954× at the lowest across every process layout measured. On one core the game had not levelled off at 16 processes, so the per-core ratio may be somewhat lower with more.

Our process is CPU-bound, so its 766 ns per action is also its CPU time. The game's figures lean in the game's disfavour in two small ways: its CPU time includes the harness's own work (building the state dictionary on the game thread, JSON on the main thread), and its throughput cells include a reset of about 30 ms per fight (reloading the save and entering the room), which our engine replaces with copying a start state. In one warm process the game does 96.5 actions/s without the reset and 85.8 with it. Across all the process layouts below, the game thread's CPU per action ranges from 0.73 to 1.73 ms, so the game-thread CPU-time ratio ranges from 954× to 2,250× (whole process: 1,200× to 2,970×).

Why "23,000×" is retired

Earlier versions of this site said the engine was about 23,000× faster than the shipped game. That compared the wall time of one game process per fight, started cold, with one Rust thread: today 17.9 ms per action against 766 ns, 23,400×. Of those 17.9 ms, about 2.3 ms is the game's warm CPU work, about 7.8 ms is extra CPU a fresh process spends on its first fight (JIT compilation and cold start), and about 7.8 ms is time off the CPU in the harness's 1 ms polling sleeps. It measured that setup correctly, but it is neither a throughput nor a language comparison.

Every process carries its own Python driver on the same CPUs. Warm processes play 220 untimed fights first. The game never fills the CPUs: with 384 processes they are 86% busy and throughput is already lower than with 192. The whole-machine best is 61% of 24 × the one-core best. All layouts of a group played the same fights with the same digest, and 66 reference fights replayed step for step as in the earlier measurement.

Search speed

The browser hint's MCTS search on a fixed position (seed BENCH1, the first fight: Fuzzy Wurm Crawler at 57 HP against the starter hand), the same call as the workbench's bench button. Native is one thread on one core; WASM is the browser build, in Node and in headless Chromium on the same machine, timed without the Web Worker round trip.

The advisor's position: Ironclad at Ascension 5 with a 16-card deck at 55/80 HP against the boss Vantom, where a simulation costs more than in a first fight. Eight pinned threads run 6.97× as fast as one (6.95× on the 6–17 mask). In the real game the advisor runs on the player's own PC, not on this server. Both searches keep the draw order hidden, as their deployed callers do. They were timed with the search library's old default end-of-turn widening (C 0.5, α 0.4). Both now use the run agent's wider one (C 5.79, α 0.44), which made the hint's 2,000-simulation search about 8% slower natively (28.6 → 30.9 ms, same position, interleaved runs); the advisor's search has not been re-timed. The advisor's root statistics were identical on both engines in every run, and the hint picked the same first move.

On the whole machine, independent hint searches (one per process) at 1,000 simulations reach 1,490 searches/s with 48 processes and 1,480 with 24, against 72.8 on one core; at 200 simulations, 24 processes do best, 8,180 searches/s. Longer searches scale a little worse: on 24 cores the efficiency is 0.951 at 200 simulations and 0.847 at 1,000.

Training speed

Training plays whole runs: the PPO run policy for every decision outside fights, MCTS for every fight (250 simulations per decision, 1,000 at bosses). Three builds: the previous engine as training ran it before (plain build), the new engine plain, and the new engine with the profile-guided build (PGO) that training uses now. Only this project's engine appears here: the shipped game cannot copy a state for search, and the other two simulators have no run-level training loop.

Seeds 700–705 at Ascensions 0/3/6/10, the Ironclad champion, CPU 20; 3 runs per build, all nine with byte-identical game records. Part of the speed-up is not the engine: the new code skips the search when a decision has exactly one legal move.

A full iteration is the deployed Ironclad recipe: 960 games across Ascensions 0–10, 46 worker processes on this 48-thread machine, then a PPO update on one RTX 3090, starting from the Ironclad champion. The new builds play identical games. Measured as the trainer ran it, iteration 0 is distorted by one game: game 703 (Ascension 4) has an Act-1 boss fight that takes far longer than any other game, so for more than half of iteration 0 it runs alone while the other 45 workers wait. On the previous engine it ran past the trainer's 600 s stall watchdog, which dropped it, so that iteration finished only 959 of 960 games and its time is a lower bound.

The throughput measures agree: total CPU falls 2.42× (plain) and 3.37× (PGO), one core 2.46× and 3.16×, a typical iteration 2.21× and 2.93×. The GPU's share is small: the update takes 34 s of the 208 s, with the GPU 87% busy during it and idle during collection. With the 46 workers busy, the whole machine plays 21.6× the games per hour of one worker on one core (PGO build; different games, so indicative).

How "typical" was measured: the same 960-game pool replayed outside the trainer without the watchdog, once per build. The replays reproduce the trainer's new-engine collection times within 0.5% and predict the previous engine's watchdog cut at 1,175 s (trainer: 1,177–1,180 s). They ran right after the quiet-host window, one at a time with the machine about 2% busy before each, but not under its gate, so treat them as a validated estimate. A real campaign's utilisation is about 0.95, not the 0.5 of this iteration 0, but it also has rare outlier iterations: 21 of 762 in the four past Ironclad campaigns on this host hit the same watchdog. As a cross-check, the current Ironclad champion's last 150-iteration leg took 23.9 h on an older engine, close to the 25.4 h projected for the previous one.

Other simulators

This section measures two other open-source Rust simulators of Slay the Spire 2 combat, and each does something better than this project: sansb/sts2-sim certifies its fights against checksums the real game writes while it is played, which this project does not have yet, and it tracks a newer game build than the other two; lain-wood/sts2core is the fastest of the three per core; it steps a compact 3,880-byte state by value. Both were measured at the commits linked, on this machine, with our own harnesses built against their public APIs.

Clairvoyance is a property of a search, not of an engine: every engine here steps a concrete state, ours included. No benchmark in this section runs a search, so it affects none of these numbers.

Lines of code: cloc, Rust code lines without comments or blank lines, in-file test modules included, for each project's engine source directories. Test shares are a heuristic count (lines from a #[cfg(test)] module to the end of its file, plus test files). sansb's and sts2core's directories include their solvers; ours keeps search in separate crates, counted in the 365,739.

Random play, one core (W1)

The workload of the sections above. The other engines merge identical actions, so their own "uniformly random" player picks among fewer moves (it ends its turn more often) and plays a different, shorter game. Our harnesses therefore also give them the instance player: one choice per card in hand per target, the same random player as ours and the game's. Its weighting is our harness code, running inside their timed loop. With their own players, which play different games, their action rates are 0.7% (sansb) and 1.7% (sts2core) higher (medians in the table), and the ratios are 3.12× (sansb, ours with no relic) and 1.59× (sts2core).

Paired by round: ours ÷ sansb is 3.13× with no live relic on either side (Burning Blood is held but inert in sansb, whose combat-only scope leaves out its after-fight heal) and 3.39× with ours live. Ours ÷ sts2core is 0.640: sts2core is 1.56× faster, with Burning Blood modelled on both. Our engine is 7.6% slower with no relic than with Burning Blood on identical fights (it runs 3.1% more instructions per action); the cause is not investigated, so both figures are given.

Best against best (in bold): ours ÷ sansb 3.52× (ours with Burning Blood live, as in the per-core 3.39×; about 3.25× like for like, scaled by the one-core ratio; there is no relic-free whole-machine run), ours ÷ sts2core 0.692 (sts2core 1.44×, Burning Blood live on both). The second hardware thread helps ours (+3% across the machine), makes no difference to sts2core and costs sansb 14.5% (48 threads ÷ 24 cores = 0.855).

sansb's own benchmark fixture (W2)

sansb's sts-sim bench plays 240,000 random playouts from one Ironclad start state against two Toadpoles (68/80 HP, no relic), allocating a new state for every step. The fixture leaves the ascension field out, which sansb reads as Ascension 10, so all three engines play it at A10. Our "copy per step" mode does what sansb does; "in place" is how our own searches step.

Ours ÷ sansb with the same player: 1.63× copying per step, 2.95× in place. Ours ÷ sts2core: 0.335 copying, 0.610 in place. On this fixture our lead over sansb is smaller than on W1, and sts2core's lead over ours larger.

Published figures come from the authors' own machines (sansb: an Apple M5 Max; sts2core: a Windows PC), so only the re-run column is comparable with the rest of this page.

What makes the comparison fair, and where it is not

• The same work. With the instance player, random play agrees per encounter: sansb with ours on 19 of the 22 encounters within two fight-level standard errors (which understate seed noise on randomized rosters), sts2core on 14. sts2core's largest gaps are Cubex Construct (+18 points; its monster differs from the game's code) and Flyconid, Mawler and Snapping Jaxfruit (+9 to +13; not traced). On Slithering Strangler ours is the outlier: 12.8% against 10.3% and 10.2% (12.0% over 1,600 seeds, whose 200-seed blocks vary by 0.7 points), unexplained. On Slimes (weak), sansb plays 0.86 more actions per fight than ours, unexplained.
• Merged action lists make each engine's own random player a different player; compare actions per second, or use the instance player, never fights per second across players. Merging also shrinks a search's branching; a per-action benchmark does not credit that.
• Burning Blood is inert in sansb; hence the no-relic comparison.
• Stepping. sansb allocates a state per step and sts2core copies 3,880 bytes per step; ours mutates one state. W2's copy mode puts ours on sansb's terms.
• Game build. sansb models v0.111.0, ours and sts2core v0.107.1. The W1 monsters' HP bands are identical between the two builds at A0, and none of the monsters on sansb's v0.110.1→v0.111.0 change list appears in W1; the v0.107.1→v0.110.1 changes are not documented there, and movesets were not audited.
• RNG. sts2core draws its own random numbers, so its fights match ours in distribution, not seed for seed; sansb and ours reproduce the game's streams but enumerate actions in different orders, so the same random player still picks different moves.
• Builds. Each engine uses its own release profile (table above). None uses target-cpu or PGO, and all use the system allocator.
• W2 is an A10 fight. Read at A0 by mistake, and with our harness opening the back Toadpole with the wrong move (since fixed, see Method), it once looked like a 10-point rules disagreement between sansb and the other two; at A10 all three agree within about one point of win rate, and turns 1 and 2 match exactly. From turn 3 on, sansb's playouts run about 3–4% more actions (19.3 per playout against 18.7 and 18.5), unexplained.

Method

• When and where. 14 October 2026, 10:59–16:33 UTC, on the machine above. Before every timed stage the host had to be quiet: 1-minute load below 1.5, the whole machine below 3% busy over 5 s, and the stage's own CPUs and their SMT siblings below 5% busy. At the 58 gate passes the load was 1.38 and the machine 2% busy (medians). Whole-machine runs, ours and the game's, used the whole-machine part of the gate only, because background noise from other users on single CPUs never let the per-CPU check pass for the game's cells. The training stages checked only the whole-host busy share (≤ 3%); the 1-minute load at those 15 gate passes was 1.09–7.3.
• Pinning. Single-threaded runs on CPU 20 with CPU 44 idle; WASM on CPUs 18–23; the advisor as in its table; the game's one-core cells on CPUs 20 and 44. Whole-machine runs fork every process, pin it, and release all of them at the same instant.
• Interleaving. Previous and new engine alternate (previous, new, new, previous, …): 7 pairs for random play, 5 for each search runtime, 4 for the advisor; the three training builds run in reversed order every round (3 rounds on one core, 2 full iterations). Cross-engine runs rotate their order every round. Values are medians; speed-ups are medians of the paired ratios.
• Identity checks. A timing ratio is only a speed-up if both sides did the same work, so every harness prints a digest of it: every fight's length and outcome, a search's root statistics, a position fingerprint, or a hash of every training record. All 111 checks passed, and no published run was forced on a busy host.
• A harness fix. Before this benchmark, our random-fight harness built monsters through a debug scenario builder whose monster AI and HP rolls differed from a real run's. It now builds them as a run does. The random-play statistics barely moved, but the numbers on this site before 14 October 2026 used the old builder; site_random_bench --legacy-spawn reproduces them.
• Not covered. Other hardware: no desktop or laptop CPU, no ARM, no Windows, no phone or tablet browser. The real game with its renderer. The advisor on a player's PC with the game running.

The full write-up, with every value unrounded, the reproduce commands, the identity checks and what was left out and why: sts2-rs/docs/perf/2026-10-14-benchmarks.md. Harnesses: site_random_bench.rs and xsim_toadpoles.rs (random play, W2), hint_bench.rs (the hint's search), and scripts/site-bench/ (whole-machine runner, the shipped game, WASM, advisor, training, and the harnesses for the other two simulators).