SimpleChess 3.1.0 — a from-scratch NNUE engine with no external training data

[mysammoore]

I've posted around here before but never about anything of my own, so this is a first. SimpleChess 3.1.0 is out at https://github.com/LinkLikesLattes/SimpleChess under GPL-3.0, and the thing that makes it worth a look is the training data, or rather the lack thereof. The network has never seen a Stockfish evaluation, a Leela evaluation, or any public NNUE dataset (labelled positions or otherwise (note, its endgame eval is very optimistic or pessimistic in 0.00 positions, though this does not affect quality of play)). It was originally bootstrapped from HCE evaluations alone (SimpleChess 1.8, the final HCE version), and every generation since has been trained on the engine's selfplay labelled by its own search (switched from pure HCE labels, to a mix, to pure NNUE by net gen 7). That lineage doesn't make it stronger by itself, but it does mean the evaluation arrived at its opinions independently, and its mistakes are its own rather than a lossy copy of someone else's. If you test a lot of engines that all descend from the same data, this one should feel different, and I'd be genuinely interested to see where it disagrees.

Under the hood it's C++20, a HalfKAv2_hm input, king-bucketed and mirrored, extended with full threat features and three-wide pawn pairs, a 512-wide accumulator and int8 inference (current net trained on 880M positions from a fixed 3.9M lines that seed selfplay), sitting behind a conventional alpha-beta with aspiration windows, null move, LMR, SEE pruning, TT, the usual move ordering and lazy SMP. Syzygy WDL probing arrived in this release through Fathom, interior nodes and root filtering, verified against python-chess and shipped as correctness-only since I never measured a strength gain from it myself. Move generation is a vendored header-only library, everything else is mine.

The other half of 3.1 was speed, and I ran it as two disciplined campaigns rather than a grab bag. Every candidate had to produce identical nodes, score and PV against 3.0.0 at fixed depth on 28 positions before it was allowed to count, and was then timed in interleaved A/B/B/A sessions with role and order swapped, because the noise floor's sign flips with position order. Fifty-two items tried on x86/AVX2 and twenty-eight kept, twenty-four tried on NEON and five kept, and four of the x86 wins turned out not to hold up on ARM at all and are now guarded off. The result is +131% single-thread on AVX2 and +59% on Apple Silicon, which takes it from 45% and 61% of Stockfish 18's node rate at four threads to roughly 90% and 97% on my thirty-position suite. Because every item was bit-identical, all of that is node rate turned into depth.

For playing strength, it plays in Lichess's bot pool as SimpleChessNNUE at 2822 bullet, 2816 blitz and 2801 rapid, all established (1,000+ games) rather than provisional. Mapping that onto the CCRL scale through a regression model I fitted across 22 engines that appear in both pools puts it somewhere around 3300 to 3400 (given unknown self-hosted hardware on Lichess), and that's the number I'd use as a starting point for CCRL pairings.

Both of the things that landed in 3.1 are the reason this is the release I'm posting rather than an earlier one, because both of them are about being testable under the conditions this forum actually uses. CCRL mounts tablebases and points each engine's SyzygyPath at them, and SimpleChess 3.0 and earlier did not support this. The other half is that CCRL runs on x86, and the x86 path had never had a tuning pass of its own, it was sitting at under half of Stockfish 18's node rate while the ARM side had been worked over repeatedly (because 99% of this engine's dev work has been done on my MacBook Pro).

One caveat before anyone asks, this is a source release and there are no binaries in it. If anyone does compile and test it I'd be very happy, and feedback of any kind is welcome. Notably, very few bugs have ever shown during monitored Lichess games, but only bit-identical changes have occurred since switching to NNUE, so there hasn't been much chance for bugged play to appear....