Fifteen solvers, ours and our implementations of the community's two record backtrackers, each run once on ten corner-pinned variants of the official puzzle, single core, 60 seconds per run. The finding: node count is not score.
Give every solver the same budget, one core and one minute, and which one wins?
The answer overturns the obvious intuition. Several solvers, ours and our
implementations of the community's two record backtrackers, each ran once on ten
corner-pinned variants of the official puzzle, single-threaded, 60 seconds a run.
Every board was re-scored by one canonical scorer; no engine's self-reported
score is trusted. The maximum possible score is 480.
Every engine here is our code
blackwood_style and verhaard_style are our from-scratch
implementations of Joshua Blackwood's and Louis Verhaard's published
algorithms, not the authors' own programs. Verhaard's eii only ever shipped
as a Win32 binary, so a re-implementation (its constants recovered from
eii.exe) is the only way to run it at all. Blackwood's real C# ispublic, but it hardcodes
its 256 pieces and its thread count, so it cannot read this grid's variants or
be pinned to one core without editing it. Scores here measure our reading of
each algorithm, not the authors' engineering, and should not be quoted as
"Blackwood scores N".
The leaderboard below shows the methods that compete on score. A second family,
the CSP presets (one arc-consistency engine run under a dozen ordering knobs),
is a different category: its best preset reaches about 183, less than half a
contender's score, so it earns no leaderboard row. That preset sweep is a study
in its own right, on its own page.
The two record backtrackers dominate this budget. Our Verhaard-style engine
reaches a mean of 440.8 (best 451) and our Blackwood-style engine 436.4
(best 440), both exploring 20 to 40 million search-nodes per second. Nothing
else comes close: naive DFS lands at 365.6, and the best CSP preset at about
183.
The gap between those two groups is the finding. All four families see the same
puzzle and the same 60 seconds, and they finish 250 points apart. What separates
them is not speed: the CSP engines are three orders of magnitude slower per
node than the backtrackers and still beat naive DFS on friendly variants,
because each node is pruned rather than merely visited. Node count and score are
not the same axis.
What this grid cannot tell you is where the ceiling is. The best board here (451)
is still 13 points short of the community's 5-clue record of 464, and the top
engine's mean sits about 24 short; the records were not set in a minute, they
came from farms and months. This measures
per-core efficiency at a fixed small budget, nothing more.
The leaderboard
Mean score over ten corner-pinned variants, single core, 60 s each. The methods that compete on score; the CSP-preset ablations live on their own page. Colour marks the family.
backtrackernaive DFS
Drawing…
Every algorithm across all ten corner variants
One 60 s run per cell, shaded against this table's own range. The backtrackers are flat near the top; the CSP engines are bimodal, collapsing to ~55 on hostile corners.
The two backtrackers are the top of this board and they are stable there: the
Verhaard-style engine spans 437 to 451 across the ten variants, the
Blackwood-style engine 431 to 440. The naive baseline is the floor: a fast,
junk-filled 365 that shows what raw matched-edge count looks like without any
board quality.
Throughput units differ by family and are never cross-compared. The backtrackers
count search-nodes per second, the CSP engines the same but at 5 to 10 thousand,
because each of their nodes runs full arc-consistency. The CSP family trades
throughput for pruning, which is why it explores far fewer nodes yet still beats
naive DFS on good variants.
Verhaard and Blackwood (backtrackers, ranks 1 to 2). Depth-gated-break DFS
at 20 to 40 million nodes per second. They punch to 437 to 451 but hit a wall:
the endgame needs far more compute than 60 seconds allows. Blackwood found his
470 after about a month on a single PC, and called it "a stroke of luck"
(message 10194).
Naive DFS (the baseline). Fills the whole board allowing every break. In
row-major order (anjou-naive_rowmajor) it reaches a high matched-edge count
(365) but a low-quality board full of breaks. Fast, and junk. It sits on the
board as a floor: the number a method has to clear to be worth
anything. (The visit-order sensitivity of naive DFS, and why the spiral variant
collapses to 78, is on the CSP presets page
alongside the other same-engine ablations.)
This grid caps every engine at one core for 60 seconds, far below the compute
that produced the records below. It measures per-core efficiency and heuristic
quality, not peak reachable score. An engine that ranks high here reaches good
boards cheaply; the record numbers need many cores times hours.
Every variant here pins all 5 official clues (plus 3 corners, so 8 hints in
total), so the relevant ceiling is the 5-clue community record of 464, not
the all-hints 470 (which uses more than the 5 clues). That 464 is what the
leaderboard's dashed line marks.
reference
score
conditions
Community 5-clue record
464
Benjamin Riotte, July 2026 (same 5 clues these variants pin)
This grid's best (Verhaard-style)
451
one core, 60 s (mean 440.8 over 10 variants)
Blackwood-style in this grid
440
one core, 60 s (mean 436.4 over 10 variants)
Community all-hints ceiling
470
Blackwood, ~1 month on a single PC, uses more than 5 clues
Each of the ten variants is the official puzzle plus three pinned corner cells
(distinct corner-piece arrangements), so all ten share the 256-piece set and 5
clue hints but differ in three corner constraints. They are emitted as both
site-schema JSON (for the native engines) and CSV (for the standalone engines)
from one generator, so every algorithm sees identical instances. One run per
puzzle, fixed seed; the corner arrangement is the only diversity axis. Every run
emits a bucas .url, and the score is the canonical matched-edge count from the
same scorer, never the engine's self-report. There were zero failures across all
150 runs.
Every engine in the grid is our own open-source code and runs from this
repository, including the two written from the community's published algorithms;
no third-party solver is vendored here. The grid measures all
of them; the leaderboard above shows only the five that compete on score, and the
CSP presets page
shows the rest. The crate workspace, the ten variants, the committed per-run
results and the grid scripts all live under the experiment's
backing directory,
and just experiments single-core-benchmark builds the engines and reruns the
whole grid. The native family (the naive and CSP presets) is one binary selected
by preset; the two backtrackers are a binary each, driven by a small wrapper.
Both speak the same puzzle-in,
bucas-url-out contract, and every board is re-scored by the one canonical scorer.
Profiling put 96.6 percent of the CSP family's time in one heavily pre-optimised
AC-3 loop. That engine is already at its performance ceiling; the benchmark
speeds are its real speeds, not an implementation gap. Separately, the
community's Blackwood constants do not
transfer across colour labelings: its published privileged colours scored 387 in
our labeling versus 435 for a re-fit, a 48-point gap that our Blackwood closes by
re-fitting only the labeling-relative colour IDs while matching every structural
element of the published spec.
The grid runs our implementations. Two of the community's three record engines
can in principle be run directly, and that is the obvious next measurement:
Peter McGavin's C generator. He posted the source to the list in January
2026 as genbody71.zip
(message 11749). It builds on
Apple silicon with clang and its generate pass emits a 10,363-line body.c
specialised to one puzzle. It is the fastest engine the community has
measured, at 295M placements/s on Joe's CPU
(message 11750), and it is
absent from this grid.
Joshua Blackwood's C#.Public and
GPL-3.0; it builds
unmodified on .NET 8. But it hardcodes all 256 pieces in Util.cs, fixes
number_virtual_cores = 64, and takes no arguments, so pinning it to one core
or feeding it this grid's variants means editing his source, at which point
the artifact is no longer purely his. Running it as published, on the plain
puzzle, is the faithful form of that measurement.
Louis Verhaard's eii cannot be run at all: the download from his own
site ships eii.exe and no source, which is why our engine reconstructs it
from the binary.
Neither engine is vendored into this repository; both are fetched and run
locally when measured.