VeryChess introduces multi-threaded search based on the Lazy SMP approach, with support for 1 to 256 search threads and a shared lock-free transposition table.
Author: Oleh Sych Rating Chess Engines Diary CEDR=2803
In our tests, the previous version, 0.4.0, competed in the Chess Engine League qualifying round in Group E, but ended up a distant 35th, scoring just 4.5 points out of 70 games. Now we’ll see how the latest version measures up.
Verychess 0.8.0 what's new?
Overview
This release makes the engine both stronger and — by a wide margin — faster. Three changes each add roughly twenty to thirty Elo: a clustered transposition table, internal iterative reduction, and a fix to how pinned pieces are evaluated. Separately, the search itself now runs about 2.7× faster than 0.7.0 did, mostly because sliding-piece attacks are now magic bitboards instead of a step-by-step ray walk, and because the macOS build was discovered to have been running emulated. Windows users now get two binaries to choose from.
Strength
In the roundrobin tournament with older versions VeryChess 0.8.0 shows significant increasing strength:
name games wins draws losses score elo
1 VeryChess 0.8.0 150 72 62 16 103.0 236
2 VeryChess 0.7.0 150 57 61 32 87.5 187
3 VeryChess 0.6.0 150 38 69 43 72.5 141
4 VeryChess 0.5.0 150 20 34 96 37.0 0
What's new
Clustered transposition table
The transposition table used to hold one entry per index, so two positions that hashed to the same slot simply evicted each other. Instrumentation showed the cost plainly: a 12.5% hit rate, with 32.5% of all stores overwriting a different position. Each index now addresses a cluster of four entries occupying exactly one cache line, so probing all four costs no extra memory latency, and a deep, valuable entry is no longer thrown away by a shallow one that happened to collide with it.
This one is worth a note for anyone comparing engines at fast time controls: the same change measures nothing at all (+2.9 ± 18.3) at 30+1. A larger table only helps once the search actually fills it, and blitz searches never get there. The gain appears as the time control lengthens.
Internal iterative reduction
When the transposition table holds no move for a node, the move ordering at that node is poor, and a full-depth search is largely wasted effort. The engine now searches such nodes one ply shallower, which is a cheaper way to obtain a good move for the table; later visits and re-searches then benefit from the improved ordering.
Pinned pieces no longer get imaginary mobility
Mobility evaluation counted moves that a pinned piece cannot legally make. A knight pinned against its own king was credited with all eight of its jumps, although every one of them would expose the king; a pinned bishop was credited with both diagonals rather than the one it is confined to. The engine now computes absolute pins and restricts a pinned piece's mobility to the squares along the pinning ray.
Sliding attacks: magic bitboards
Rook and bishop attacks were computed by walking each ray one square at a time, on every single call — which profiling showed to be 45% of all CPU time. They are now a single multiply-and-shift table lookup ("magic bitboards"), 26.7× faster in isolation and worth +87.8% to whole-engine speed. The attack tables are built at startup by the same ray-walking code they replace, so their contents are identical to the old implementation by construction.
Comments
Post a Comment