| Age | Commit message (Collapse) | Author |
|---|
|
Confirmed self-play regression traced to a stale test_vs_head.sh reference
binary (typhoon_allbitboards/550ea81, deleted): every "vs head" comparison
since 92fc412 (Sep 4) was checking new work against that fixed Sep-4
snapshot, never against real HEAD or the working tree. Rebuilt clean
reference binaries directly from git and re-verified everything from
scratch.
This commit lands only the pieces confirmed safe against clean 434fa04
(fast st1 match, ~30-40 games, score ~0.44-0.55, consistent with parity;
plus a DEBUG-build smoke test pass):
- recogn.c, fen.c: real bugfixes
- data.c, draw.c, ics.c: whitespace only
- x64.asm: retires the asm GetAttacks implementation now that chess.h's
GetAttacks macro unconditionally selects the already-verified-faster
_GetAttacksBB bitboard version instead of a three-way build-flag
toggle (GETATTACKS_BITBOARD/CROUTINES/asm default)
- see.c, testsee.c: SEE/test-harness updates supporting that default
- root.c: per-tier eval-exit reporting (super-lazy counters currently
always read 0 -- accurate, since no super-lazy exit exists yet)
- main.c: startup banner update, InitEval() call, TestRecogn() added to
the #ifdef TEST self-test sequence
- command.c: InitEval() DNA-reload hook, new qsearchfutility diagnostic
- dynamic.c: minor changes
- chess.h: the GetAttacks default change above, three
FUTILITY_BASE_MARGIN_* compatibility aliases (all still equal to the
original flat FUTILITY_BASE_MARGIN -- search.c has not been split into
per-tier margins here), placeholder super-lazy counters, and an
EvalPasserRaces -> _EvalPasserRacesAgainstLoneKings rename (confirmed
byte-identical body) to match recogn.c's call site
- eval.c: the same rename, plus a no-op InitEval() stub (nothing to
initialize until the ROOK_FULL_HALF_OPEN_BONUS cache below exists)
Deliberately NOT included: the full eval.c overhaul (~1770 lines) and
search.c's qsearch-futility rework (~650 lines), including yesterday's
loosened SUPER_LAZY_MARGIN_BY_ARMY/FUTILITY_BASE_MARGIN_BY_SOURCE tables.
Reverting just those two tables while keeping the rest of the eval.c
overhaul still lost badly to 434fa04 (0.20 over 10 games), so the
regression isn't fully explained by the margins alone -- the eval.c
overhaul needs careful, incremental re-verification against this commit
as the new baseline, not a bulk re-apply. Full original work preserved in
git stash (stash@{0} as of this commit) for that follow-up.
Note: two pre-existing, position/state-dependent assertion crashes were
found during this verification (util.c:1093 WalkPV, recogn.c:1359
_SanityCheckRecognizers), both reproducing on unmodified 434fa04 -- not
introduced by anything here, not yet root-caused.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Ka9o3S2eKqh4jNfmxVZ6fH
|
|
default on
Implements the full board_representation/MOVEGEN_MIGRATION.md scope:
bitboard-backed generators for all six not-in-check piece types plus
the JumpTable-avoiding whole-node dispatch fork (_GenerateAllMovesBB),
the in-check escape path (king flight + block/capture), and
movesup.c's ExposesCheck/FasterExposesCheck/ExposesCheckEp/IsAttacked/
InCheck bitboard equivalents. Nine toggles total
(GENERATE_{KNIGHT,KING,ROOK,BISHOP,QUEEN,PAWN}_BITBOARD,
GENERATE_ESCAPES_{KING,BLOCK}_BITBOARD, EXPOSESCHECK_BITBOARD,
ISATTACKED_BITBOARD), all now on by default in GNUmakefile --
DISABLE_BITBOARD_MOVEGEN=1 opts back into the mailbox path, which
remains fully present and compiled either way.
Correctness verified via perft (Kiwipete, Position 4), the move-set
comparison harness across 20,000 random positions, all nine toggles
combined cleanly (15/15 runs, after fixing a GenerateRandomLegalPosition
en-passant-sentinel bug in the test harness), and sd10 on all three
curated suites showing zero solve-count regression vs head_reference
(the ecm_hard_quick delta traced to unrelated intervening commits).
Speed: most individual generators land near parity by design (mailbox's
per-square walk was already close to O(destination count)); the real,
consistent wins are the dispatch-layer fork (up to 23% in dense
positions) and IsAttackedBB (0.73x-0.93x of mailbox).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01AbHkVrm5KUyzLwWd3GHmo6
|
|
Board-representation migration, sections 2-3 (GetAttacks half):
- board.c: VerifyPositionConsistency's bbPieces consistency check
(migration section 2), verified clean via gmake TEST=1 with the
assert live.
- POSITION.bbPawns[2]: new incrementally-maintained per-color pawn
location bitboard (chess.h), maintained at the same 6 move.c sites
as bbPieces, populated from scratch in fen.c. Distinct from the
pawn-hash-keyed bbPawnLocations; this one needs no
SEARCHER_THREAD_CONTEXT, so it's reachable from GetAttacks's actual
call sites (which only ever have a POSITION*).
- data.c/chess.h/main.c: g_RookRayAll/g_BishopRayAll (all 4 per-square
ray directions pre-ORed) and g_PawnAttackOriginBB[2][128] startup
tables, plus FastFirstBit/FastLastBit (static inline bsf/bsr
wrappers, chess.h) -- supporting tables/helpers for the primitive
below.
- see.c: _WhoAttacksSquareBB (bitboard "who attacks square X" query)
and _GetAttacksBB (SEE_LIST-populating PoC wrapping it), side by
side with the existing SlowGetAttacks/asm GetAttacks -- not wired
into the GetAttacks macro yet (section 6), pure addition.
- testsee.c: SeeListsAreEqual made order-independent (SEE() sorts the
list right after GetAttacks returns, so order was never semantically
significant); TestGetAttacks extended to run _GetAttacksBB as a
third comparison across the existing 20,000-random-position sweep;
added an interleaved asm/Slow/BB cycles-per-call benchmark across
opening/middlegame/endgame positions.
- testsup.c: fixed GenerateRandomLegalPosition (used by the sweep
above) to maintain bbPieces/bbPawns at its two hand-placement sites
-- a latent gap since section 1 that made its own
VerifyPositionConsistency legality gate almost always reject
generated positions, causing large, variable retry-loop slowdowns.
Verified: 20,000-position x every-square x both-colors correctness
sweep passes (gmake TEST=1), precommit_check.sh clean (self-test +
DEBUG smoke test). Benchmark: _GetAttacksBB is ~0.53-0.55x asm
GetAttacks's cycles/call (opening/middlegame) and ~0.89x (endgame) --
faster, not just equivalent, primarily from replacing bbOccupied's
up-to-16-iteration pawn loop with two bbPawns ORs, plus a
g_PawnAttackOriginBB table lookup replacing per-call pawn-delta
arithmetic and per-direction/per-side-group early-outs in the slider
walk. See board_representation/MIGRATION.md section 3 for the full
writeup, including a reverted approach that measured slower and why,
and the CountKingSafetyDefects half's re-scoped (not yet implemented)
design.
Also confirmed (not caused by this work, not fixed here): a
pre-existing non-deterministic MP-race assertion in util.c:1093's PV
printing, reproduced independently on a clean HEAD checkout.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Jntky4yGUTyQVaGCXms4F2
|
|
Board-representation migration, section 1: add POSITION.bbPieces[2][8]
(per-color, per-piece-type location bitboards, indexed like the
existing uNonPawnCount) as incrementally-maintained state, not a
per-Eval()-call rebuild -- the structural fix for why the earlier
attack-presence-bitboard work measured slower, not faster.
- chess.h: bbPieces[2][8] field; extern decls for data.c's
g_RookRayToEdge/g_BishopRayToEdge/g_KnightAttacksBB ray tables and
their Initialize* functions (needed by the planned bitboard-backed
GetAttacks/CountKingSafetyDefects primitive, section 3).
- fen.c: populate bbPieces during piece placement; zeroing is free via
the existing memset(p, 0, sizeof(POSITION)).
- move.c: maintain bbPieces at all 6 non-pawn piece-movement functions
(SlidePiece/LiftPiece/PlacePiece and their WithoutSigs siblings used
by UnmakeMove) -- covers every move type: normal moves, captures,
both-side castling, promotion with/without capture, en passant, and
every undo.
- board.c: extend VerifyPositionConsistency's existing non-pawn
piece-list walk with a parallel bbPieces reconstruction-and-compare,
rather than a separate bespoke check.
- data.c/main.c: pulled ray-to-edge/knight-attack tables from stash
(needed by section 3, not section 1 itself, but zero-risk to land
now).
Also, while verifying: COOR_TO_BB was a table lookup (BBSQUARE[idx])
measured ~5-7% slower than the pure-ALU shift already sitting unused in
SLOWCOOR_TO_BB (whose "SLOW" name reflects a stale assumption about
variable shifts never actually tested on this hardware). Switched
COOR_TO_BB to the shift; fixed testbitboard.c's existing but broken
(dead-code-eliminated, silently reporting "0 cycles/op") comparison
benchmark for both while at it.
Verified via gmake TEST=1 (including TestMakeUnmakeMove's explicit
en-passant/promotion-with-capture/both-castling coverage) and
debug_smoke_test.sh, both clean; release build clean and runs normally.
Nothing reads bbPieces yet -- pure addition, zero behavioral risk.
See board_representation/MIGRATION.md for the full plan.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Jntky4yGUTyQVaGCXms4F2
|
|
Clean gmake GENETIC=1 PERF_COUNTERS=1 MP=1 SIXTYFOUR=1 build had 100
warnings; DEBUG=1 and TEST=1 builds had more once actually exercised.
- OFFSET_OF/CONTAINING_STRUCT (chess.h) and PTR_TO_ALLOC_HASH (unix.c)
truncated pointers through 32-bit ULONG before use in offset/hash
arithmetic on this 64-bit build -- routed through size_t instead.
- Diagnostic int<->void* round-trips (command.c, root.c, split.c,
sig.c, data.c, unix.c, util.c) widened/narrowed via size_t to avoid
implicit truncation.
- ABS_DIFF on unsigned COOR now casts to int before abs().
- Dropped -fexpensive-optimizations (GCC-only, clang silently ignores
it) from GNUmakefile.
- Removed genuinely dead variables (book.c, gamelist.c, split.c,
testgenerate.c, testhash.c).
- Guarded DEBUG/PERF_COUNTERS/_X86_-only variables and the
_CMEvidenceBucket helper under the #ifdef that actually reads them,
since ASSERT/EVAL_TERM/KEEP_TRACK_OF_FIRST_MOVE_FHs compile away
outside those builds.
- Added missing prototypes for SlidePawn, SlidePawnWithoutSigs,
SlidePieceWithoutSigs (move.c), previously undeclared in chess.h.
- Removed dead _SystemIsRoot (unix.c).
Verified via precommit_check.sh: TEST=1 self-test suite passes,
DEBUG=1 smoke test (10 random ECM positions, sd 4) passes with no
crashes/assertions, release build restored -- all three profiles now
build with zero warnings.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_014Cmv11sJZqVfanrPh6UnWE
|
|
NumLeftoverMovesToSelect, indexed by remaining depth; make EFP's
leftover-only scope explicit.
SEARCH_SORT_LIMIT[ply] was a poor proxy for what actually matters here
-- how large the remaining subtree below this node is. Distance from
root only correlates with that when total search depth is roughly
fixed; it says nothing once extensions/reductions/iterative-deepening
are in play. NumLeftoverMovesToSelect(ctx, uDepth) uses remaining depth
instead, only ever consulted once every high-performer move (winning/
even capture, killer, killer-mate -- anything >= GOOD_MOVE) has already
been exhausted; this never limits how many of *those* get selected,
only how much further care to spend on the ordinary/leftover tail.
Table values carried over verbatim from the old one as an untuned
starting point, just reindexed.
Also adds an explicit (TRUE == fInLeftovers) gate to EFP's per-move
checklist (landed last commit) -- every high-performer move was already
excluded as a side effect of the capture/check/killer exemptions, but
this makes "EFP only ever touches leftovers" a real, direct condition
rather than an emergent property of unrelated checks.
Verified against HEAD (commit bb07fbd) at sd10:
ecm_ringers: 9/11 -> 10/11 (+1 solve), ~flat nodes (-0.04%)
ecm_confident_quick: 88/90 -> 88/90 (even), +0.43% nodes
ecm_hard_quick: 15/90 -> 18/90 (+3 solves), +4.4% nodes
Net +4 solves across 269 positions for a negligible node-count cost.
|
|
EBF/beta-cutoff/counter-move stats, script.c FPE fix.
No LMR, no counter-move-driven move ordering (both explored separately,
kept out for now -- counter-move measured worse, ~655->647 solved on
ecm879 @ sn=4M with a leaner tree beforehand). Futility pruning restored.
Verified: 647/879 solved, EBF 4.609 @ sn=4M; 684/879 solved, EBF 3.995
@ 20s/move, 1cpu, 256m hash (typhoon_baseline.log).
The counter-move table is still written and its stats still tracked
(dynamic.c) for diagnostic purposes, but generate.c no longer reads it
for move ordering, so it has no effect on search behavior in this
commit.
lmr_testing/ holds the in-flight graded-LMR + counter-move code (not
applied here) with notes on what was already tried and measured, so a
future session can resume without re-deriving it.
|
|
|
