diff options
| author | Scott Gasch <[email protected]> | 2026-09-18 23:43:55 -0700 |
|---|---|---|
| committer | Scott Gasch <[email protected]> | 2026-09-18 23:43:55 -0700 |
| commit | b70be6fde0fef0694e404e16d70f00c73dd971a2 (patch) | |
| tree | d5523636bf76bd53f8ac4a60e508c458fa3c2a51 /src/suite_picker.pl | |
| parent | 004a5736c6d41747d8fc0e15d230ab80bd6cced6 (diff) | |
see.c: replace _WhoAttacksSquareBB's ray-walk with magic-bitboard lookups
_RookAttacksBB/_BishopAttacksBB (generate.c) are already O(1)
FORCEINLINE magic-table lookups, proven and already used everywhere
else in this codebase (eval.c, searchsup.c, generate.c's own move
generation) -- this function alone predated that migration and was
left on a manual per-direction ray-walk (4 rook + 4 bishop directions,
nearest-blocker isolation via FastFirstBit/FastLastBit). King handling
is also branchless now: king adjacency is symmetric, so
g_KingAttacksBB[cSquare] doubles as "every square a king standing
there would attack cSquare from," same O(1)-table-lookup shape the
knight line already uses -- no DISTANCE()==1 branch needed.
Old ray-walk kept as _WhoAttacksSquareRayBB, testsee.c's
TestWhoAttacksSquareMagic correctness-diff reference (20000 random
positions x every square x both colors, clean) -- same convention as
_AddXRaysMailbox next to _AddXRaysBB from an earlier SEE investigation
this session.
Isolated benchmark: magic is 0.95x-0.99x ray-walk in a standalone
3-position microbenchmark (small, since the ray-walk already has its
own early-out for "no slider anywhere near this square," per its own
header comment). Measured end-to-end (sd10 + sn5M, all three curated
suites, before vs. after): node counts and solve counts bit-for-bit
identical (pure algorithmic swap, zero behavior change). Wall-clock
~0.8% faster overall, all 6 measurements faster, none slower.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Diffstat (limited to 'src/suite_picker.pl')
0 files changed, 0 insertions, 0 deletions
