pawn

A UCI alpha-beta chess engine, largely inspired by Stockfish.

As with most UCI chess engines, pawn should be used with a compatible graphical user interface (such as CuteChess). It plays both standard chess and Chess960.

The engine uses an efficiently updatable neural network (NNUE) for evaluation. Currently, the net is shallow with a single 256-neuron layer and 4 output buckets (selected according to the number of pieces on the board). A separate set of PSQ tables is directly propagated to the output, which is also initialised using the material values of each piece. All training data has been generated in self-play at low depth using the tools in the branch data_gen. The training scripts can also be found in that branch, which use a PyTorch backend. The default network is embedded in the binary file with incbin.

Getting pawn

The latest official version can be downloaded in the Releases tab. Binaries for both Windows and Linux are available. For each platform, two 64-bit versions are provided: a generic version for most x86 processors (slower) and one with the instruction set from haswell (faster with BMI2, AVX2 and POPCNT, but may not be supported for older CPUs).

For the most up-to-date (and likely stronger) version, it is recommended to compile directly from sources for the target architecture, as described below.

Compiling from sources

To compile under Linux or Windows with MSYS2, simply call

make

in the root directory to generate an executable optimised for the building machine. The resulting binary and object files can be found in the build directory. Verify the signature of the binary by running the bench command and checking if the number of nodes searched matches the Bench field of the last commit message.

To compile generic binaries or to a specific architecture, use

make ARCH=target

where target is the target passed to -march=.

Progress

The progression of pawn in self-play since the first public version is illustrated in the table below. The ratings are computed with ordo (anchored at zero for the first commit and with errors relative to pool average) using the noob_3moves book under LTC conditions (single-thread with TC 60+0.6 and 64MB hash).

UCI Options

The following UCI options are supported:

• Hash

  Size of the Hash Table, in MB (defaults to 16).

• Threads

  The number of threads to use during search (defaults to 1).

• MultiPV

  The number of principal variations (PV) to search (defaults to 1). This should be kept at 1 for best performance.

• Ponder

  Allow the engine to think during the opponent's move (defaults to false). This requires the GUI to send the appropriate go ponder.

• Move Overhead

  Extra time to reserve for each move (defaults to 0). Increase if the engine flags due to communication delays.

• Clear Hash

  Button to clear the hash table.

• NNUE_File

  Path to the NNUE net file to use (empty by default). If empty falls back to the embedded network file.

• SyzygyPath

  Path to the directory containing the Syzygy endgame tablebases.

• SyzygyProbeDepth

  Minimum depth to probe the endgame tablebases during the search.

• SyzygyProbeLimit

  Maximum number of pieces to allow probing the table.

Furthermore, the following non-standard commands are available:

• board - show a representation of the current board;
• eval - print some of the evaluation terms;
• test - test the move generation, transposition tables, move orderers and legality checks of the engine;
• bench - search a set of positions to obtain a signature. Optionally, the following syntax is available: bench depth threads hash. By default, calling bench is equivalent to bench 13 1 16.
• go perft depth - do the perft node count for the current position at depth depth.

Main Features

Syzygy endgame tablebases

The Syzygy endgame tablebases support uses Fathom for probing the WDL and DTZ tables. Similarly to the original implementation in Stockfish, pawn has two modes of operation:

• If the root position is not on the tablebase, pawn will probe the WDL tables during the search (only after a move that resets the 50-move rule counter);
• If the root position is on the tablebase, then only the moves that preserve the root's WDL score are searched. The engine will continue to search on these moves, but the reported score is derived from the tablebase (unless a mate score is found). To avoid wasting moves in long conversions or possibly drawing by repetition, DTZ tables are used to make progress whenever two-fold repetitions may arise. When using go searchmoves, the move selection is ignored, but TB scores are still returned.

Board representation

• Bitboard representation (with GCC builtin bitscan and popcount)
• Magic numbers for slider move generation
• Staged move generation for captures and quiet moves

  Evaluation

• Efficiently updatable neural network (NNUE):
  • Combined PSQ and layer contributions
  • HalfKP_hm feature set
  • Four output buckets, selected according to the number of pieces on the board

    Search

• Principal Variation Search in a negamax framework
• Quiescence search with SEE
• MultiPV search
• Transposition Tables
• Aspiration Windows
• Late move reductions
• Null-move pruning
• Singular and check extensions
• Futility pruning
• Mate distance pruning
• Basic Lazy SMP threading

  Move Ordering

• MVV move ordering for captures
• Killer moves
• Quiet move ordering
  • History heuristic with butterfly and 3-ply continuation piece-to boards