# How the record solvers search > How the solvers that hold the records actually search. They are all, at heart, depth-first backtrackers; what separates them is the order they try things and how they bend the rules near the end. - Canonical page (with interactive figures/demos): https://eternity2.dev/research/build/solvers/ - Updated: 2026-07-21 - Topics: backtracking, speed --- Every solver that holds a serious Eternity II record is, at heart, the same machine: a depth-first backtracker. What separates them is not the loop but three choices layered on top of it, the order they visit cells, the heuristics that decide which piece to try first, and how they bend the endgame when a perfect match runs out. This page is the neutral tour of those choices. The full, first-party engine story for each solver (decoded from the source and the literature, then built and measured) lives on its own lab page, linked from each section below. ## The engines at a glance Before the tour, the catalogue: one row per engine, and the four choices that set it apart. Every reach is measured single core on one machine, so the numbers compare like for like rather than across clusters; each row links its full write-up. | Engine | Fill order | Pruning | Hardware regime | Measured reach | | --- | --- | --- | --- | --- | | [Blackwood's backtracker](/research/lab/experiments/joshua-blackwood/solver) | bottom-left row scan, border pieces late | per-depth colour quota plus a depth-gated break-index budget | single core; the 470 came from many cores in parallel | 248/256 pieces unconstrained; stalls near 45 once the five clues are pinned | | [Verhaard's eii](/research/lab/experiments/louis-verhaard/eii) | comb-search orders | forward pruning against tuned score thresholds; a Markov-tuned slip schedule | single-core Win32 binary; no source to rebuild | 467/480, the only prize the contest paid | | [McGavin's C backtracker](/research/lab/experiments/peter-mcgavin/backtracker) | per-puzzle scan-row, spiral-in, or border-first | generated code plus lookup tables and counter tricks for raw throughput | single core, ~109M placements/s on the real puzzle | past 200/256 pieces; built for speed, not a record score | | [Verhaard reimplementation](/research/lab/experiments/louis-verhaard/verhaard-reimpl) | set-composition swap-annealing under the 2×2 metric | annealing acceptance, constants recovered byte-exact from the binary | single core; run committed and rerunnable | 438/480 on the real five-clue puzzle | | [CSP presets, measured](/research/lab/experiments/single-core-benchmark/csp-presets) | a dozen ordering presets, border-first the best | arc-consistency propagation | single core, ten corner-pinned variants | near 183 on the corner-pinned variants; below half a contender's score | The tour below walks the three choices those rows share. ## Plain backtracking Fill the board cell by cell in some fixed order. At each cell, try every piece and rotation whose edges match what's already placed; if none fit, back up and try the previous cell differently. Correct but slow: the search tree is astronomically wide. Here is exactly that, in slow motion: a real backtracker on a 3×3, one decision at a time. Step through it and watch a piece go down, a dead end appear, and the search un-place and try again. > **[Interactive: DfsDemo]** Rendered on the canonical page (link above); not shown in this markdown export. ## Order matters: the fill path The order you visit cells changes the difficulty by orders of magnitude, because some orders force conflicts to surface early (good) and others defer them until a lot of work is wasted (bad). Border-first beats row-major by a wide margin on the same puzzle. It is the single lever every record engine tunes: Verhaard's comb-search orders, Blackwood's bottom-left row scan with border pieces interspersed late, and McGavin's per-puzzle choice of scan-row, spiral-in, or border-first are all answers to the same question. ## Heuristics: which piece first A plain backtracker tries candidates in an arbitrary order. A record engine scores them, so the pieces most likely to matter go down first, and prunes any branch that falls behind a schedule. Blackwood's solver, for instance, privileges three colours and enforces a per-depth quota that must be met to keep descending; Verhaard prunes forward against hand-tuned score thresholds. The details differ, but the shape is shared: commit the constrained pieces early, cut the branches that cannot pay their way. ## Bending the endgame: breaks and edge-slipping A perfect 256-piece tiling has never been found. Every record board instead tolerates a handful of late mismatches, and the engines reach them by *scheduling* imperfection: a per-depth budget of mismatched edges that unlocks deep in the search. Verhaard called his a slip array; Blackwood calls his the break indexes. Same idea, gated by depth so the early board stays clean and the mismatches are spent only where they buy the most. The lab below lets you move that budget around and watch the reachable score change: > **[Interactive: BreakIndexLab]** Rendered on the canonical page (link above); not shown in this markdown export. ## Read the full engine story Each record engine has a dedicated page that decodes how it works and then builds and measures it on one machine, single core: - **[Blackwood's solver, decoded and run here](/research/lab/experiments/joshua-blackwood/solver)**: the schedule-and-break-index backtracker behind the standing 470, with Jef Bucas's parameter study and a build that flies unconstrained but stalls once the five clues are pinned. - **[Verhaard's eii](/research/lab/experiments/louis-verhaard/eii)**: the engine behind the 467, the only prize the contest ever paid: forward pruning, comb-search orders, a Markov-tuned slip schedule, and why its source-less binary cannot be run today. - **[McGavin's C backtracker](/research/lab/experiments/peter-mcgavin/backtracker)**: the community's fastest engine, a 2007 optimization recipe compounded for two decades, built here and pushed past 200 of 256 pieces at over 100 million placements a second. - **[The JIT backtracker](/research/lab/experiments/raphael-anjou/jit-backtracker)**: a portable-Rust engine that generates and compiles per-puzzle code, taken rung by rung to McGavin's throughput - a tie with his hand-tuned C on hard, realistic boards (his C stays faster on easy ones) - a speed result on an [axis of its own](/research/lab/experiments/raphael-anjou/going-fast) from the score the record engines chase. - **[This site's reference engine](/research/lab/experiments/raphael-anjou/engine)**: not a record machine but the Rust/WASM backtracker that runs every demo on this wiki and checks its numbers. ## See it run The playground runs a real depth-first solver in your browser. [Watch it search live](/playground/watch), or [draw your own fill order](/playground/paths) and race it against the classics to feel how much the order matters. For approaches that don't work, see the [dead ends](/research/build/dead-ends).