Store the static evaluation in the transposition table and merge the pawn and shelter table entries

[aywrite]

Four exact changes to the evaluation and the table, one commit each. The search visits the same tree: every per position line of the bench and the games suite is unchanged (5,965,973 and 9,409,127 nodes).

1. The pair term is kept as the sum and difference of the two perspectives, so the leaf reads one dot product where it read two sums of squares.
2. The shelter table's entry holds the shelter and the pawn structure added, and the pawn table is asked only behind a shelter miss (about 11% of evaluations). Both tables are fixed length arrays and are probed before the walk.
3. Material is one white relative number read from the piece's row.
4. The table entry's two reserved bytes hold the position's static evaluation, and a full width node reads it from the entry its own probe found instead of evaluating again.

Rebased onto adfd966. Commit 4's stores go through master's new Node, and a test master added that calls search_table_move passes NO_EVAL.

Instructions. Callgrind, the tree search, against master adfd966: the games suite 11,748,841,555 to 11,398,942,426 (2.978% fewer), the bench 9,096,745,929 to 8,830,624,901 (2.925% fewer). By commit, in points of master's games suite: 0.893, 0.521, 0.663 and 0.901. On the old base b6e82bb the series saved 3.077%.

Clock. scripts/speed.sh on the rebased head against adfd966: +0.8% (95% interval −0.4% to +1.9%, 120 interleaved rounds over shuffled layouts), not resolved. The same comparison before the rebase read +2.2% (+0.8% to +3.8%) against b6e82bb. Each commit's Speed: trailer is 60 rounds against its own parent, on the rebased commits: +0.0%, +1.6%, +1.0% and +0.7%. A step of half a point to a point is below what 60 rounds resolve. An earlier clock of the same code over shuffled layouts read the whole series at +1.81% (+0.92% to +2.73%) on the games suite over 450 rounds, and +2.52% (+0.40% to +4.63%) on the bench over 80.

Games. Four Strength runs of 500 games at 10+0.1 on 8moves_v3 against b6e82bb, before the rebase, the decision fixed before the first game: the mean rate ratio of the four and its 95% interval. The runs (#258 to #261) read 1.0024, 1.0112, 1.0117 and 1.0115, so r = 1.0092 [1.0020, 1.0164], wholly above 1.000. Every game ended normally. The games returned about a third of the instruction saving, less than the search node change did, most likely because most of what this removes is arithmetic that overlaps with the walk.

Non-regression. An sprt [-10, 0] at 10+0.1 on 8moves_v3, the rebased head against adfd966, in batches of 500 up to 2,000 games: Strength #263 read +0 ±10 over 2,000 games, inconclusive at the cap (LLR 1.88 against ±2.94). The batches read −24, +8, +10 and +6, and the test moved toward the upper bound in each batch after the first. Every game ended normally.

Checked, on the rebased head. The release, debug, machine-test and baseline target test runs pass, as do the tactical and strategic suites. Master and the head search the 1,800 positions of tactics.epd and strategy.epd to depth 7 with identical nodes, scores and moves (101,372,856 nodes each), and 150 play-outs of up to 60 plies with the table kept agree at every ply (8,460 plies, 171,842,739 nodes each).

Constraints this leaves:

• The pair term's identity needs the term to stay the plain difference of the two perspectives' squared norms. A lane of the sum or difference is up to twice a perspective's, which in_range checks at compile time. On the shipped factors the i32 limit on the sums of squares still binds first (a uniform scale of 1.275 against 1.314 for the lanes).
• The shelter entry holds the pawn structure because the shelter's key holds the pawn key. A term that reads anything else cannot share it.
• The stored evaluation is exact only while the evaluation reads nothing the table key does not cover (no fifty move counter, no line, no history). A correction to the evaluation belongs after the read, and the entry keeps the raw value.
• A false accept on the table's 32 bit signature now also hands a node another position's evaluation for its pruning, and the node stores it back under its own key.
• Machine::of keeps two index loops under an allow: the iterator form clippy asks for moved the search's code by 0.2% to 0.8% of its instructions.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DtepPHhwporfDvjPSnX4ae

---

Generated by Claude Code

[github-actions]

Speed against 587f1f68

Measured on AMD EPYC 9V74 80-Core Processor.
Both sides built with rustc 1.98.1 (48a229cea 2026-09-01).

Both sides built and run on this runner in this job, the way
scripts/speed.sh measures a perf commit. Each round runs
both sides on a layout of its own, the same compiled code with
its code and data shuffled and moved, so the 95% interval carries
where the code landed as well as the run. The verdict holds the
interval against a 1% threshold. The default layout, the one a
release ships, is measured after as a diagnostic. The node
counts are the search's: they move when the search does, and a
speed change leaves them alone.

round     base nps  candidate nps  change
    1      4298852        4408059   +2.5%
    2      4222489        4247411   +0.6%
    3      4074069        4370205   +7.3%
    4      4215422        4231360   +0.4%
    5      4282285        4440775   +3.7%
    6      4162290        4241848   +1.9%
    7      4158309        4332125   +4.2%
    8      4219918        4313154   +2.2%
    9      4125583        4311851   +4.5%
   10      4128081        4301976   +4.2%
   11      4208837        4182852   -0.6%
   12      4075427        4219608   +3.5%
   13      4050521        4176156   +3.1%
   14      4116707        4310107   +4.7%
   15      4118395        4415821   +7.2%
   16      4167474        4270829   +2.5%
   17      4284533        4261744   -0.5%
   18      4332184        4340095   +0.2%
   19      4313226        4306019   -0.2%
   20      4262965        4256298   -0.2%
   21      4314215        4284112   -0.7%
   22      4099108        4252221   +3.7%
   23      3923828        3999265   +1.9%
   24      3925524        4168927   +6.2%
   25      4014724        3993178   -0.5%
   26      3989483        3860124   -3.2%
   27      4086764        4121049   +0.8%
   28      3945342        4145619   +5.1%
   29      3895255        4074305   +4.6%
   30      4119484        4149843   +0.7%
   31      3940753        4379264  +11.1%
   32      4233155        4132464   -2.4%
   33      4118358        4243664   +3.0%
   34      4383441        4418846   +0.8%
   35      4342375        4489805   +3.4%
   36      4257367        4345038   +2.1%
   37      4321543        4367169   +1.1%
   38      4237533        4404342   +3.9%
   39      3961711        4125600   +4.1%
   40      4149110        4156053   +0.2%

             nodes    time  median nps  faster half
base       5965973  1.44 s     4153710      4260921
candidate  5965973  1.40 s     4259021      4353567
change                           +2.5%        +2.2%

paired change +2.2%, 95% interval +1.5% to +3.2%
diagnostic, on the default layout alone +1.4%, 95% interval +0.1% to +4.8%, 13 rounds

faster: the whole interval is above +1.0%

Speed: +2.2% (bench nps, 95% interval +1.5% to +3.2%, 40 interleaved rounds over shuffled layouts vs 587f1f68)

The instructions each side's bench executed, counted under
cachegrind. The count repeats to within a few hundred
instructions, so a small change here is a real one, but it
prices instructions only: cache misses, mispredicted branches
and where the code lands are the speed's to show.

instructions against 587f1f68, one cachegrind run a side, bench

            instructions    nodes  per node
base       9,367,189,087  5965973    1570.1
candidate  9,084,213,562  5965973    1522.7
change            -3.02%             -3.02%

fewer instructions, beyond the ±0.7% that edits not made for speed have moved the count