I recently ran an experiment to test probing the hash table from the quiescence phase of the search. The argument for it is: qsearch is effectively a depth-0 search, so anything already sitting in the hash table was put there by a full-width search at depth 1 or deeper, which by definition did more work than qsearch would do on its own. If that entry’s bound is good enough to cause a cutoff, it’s a cutoff you get essentially for free.

So I added it to chess4j. The change was small: at the top of quiescence search, probe the main hash table.

Elo difference: -35.9 +/- 9.8, LOS: 0.0 %
SPRT: llr -2.95 (-100.1%), lbound -2.94, ubound 2.94 - H0 was accepted

Not a wash — a clear loss, and a fairly big one at that. But why?

My best guess … consider that the quiescence nodes make up a large majority of the search tree – something like 2/3.

Also consider that when you hit the quiescence phase, depth is already at 0. Those lines are usually fairly shallow.

Add a hash lookup to every one of those enormous numbers of qsearch nodes, and the nodes-per-second hit apparently outweighs whatever cutoffs it was finding.

Perhaps the outcome would be different with a different hash replacement scheme. chess4j is “always replace,” which isn’t the most cache friendly scheme to begin with.

For the sake of completeness I tried a couple of variations of gating the lookup based on depth. The first attempt was to only probe once qsearch is at least 2 plies deep.

Elo difference: 1.6 +/- 3.5, LOS: 81.4 %, DrawRatio: 42.6 %

It’s statistically neutral, but neutral is a massive improvement over -36 Elo. So naturally I pushed it further: if 2 plies helps, does 4 help more?

Elo difference: -15.2 +/- 6.5, LOS: 0.0 %
SPRT: llr -2.95 (-100.2%), lbound -2.94, ubound 2.94 - H0 was accepted

Nope. Worse than 2 plies, though still better than probing everywhere.

End result: I don’t have a version of “probe the hash table from qsearch” that’s actually worth merging into chess4j. Sometimes the answer an experiment gives you is just “no.”