Quiescence Search Performance

[theturk1234]

Thanks Sven and all of you!
I'm learning more every time I post. I'll be posting here a lot; I have so much more to learn!

David Cimbalista

[cdani]

* Try hash move even with moves that are no captures.

In some of my engines that did this (as a bug) it caused crashing in some positions, because of infinite recursion. (Especially in combination with check extension.)

I have a max level of quiescence from which only recaptures are reviewed. Also if is a repeated position I return immediately.

[hgm]

After some thinking about this I am still puzzled as why you would want to do that. If you have a hash move you have had a hit on an entry containing a lower bound on the score. As you are in QS, any draft would be sufficient for a hash cutoff, so the reason that you don't take the cutoff can only be that the stored lower bound is smaller than beta.

In addition the current evaluation would be below beta, or you would have taken the stand-pat cutoff. In general non-captures do not increase the evaluation much, so you would expect the move to be refuted by stand pat of the opponent. So you would be searching a move that you don't expect to do any good, and that on a previous more elaborate search was not shown to do good enough. This seems a lot like a 'wild goose chase'. Which percentage of such moves does actually score above alpha?

In fact I would be inclined to act on the following consideration: the hash hit shows the position has been searched before, and the fact that a non-capture became hash move shows that none of the captures was any good. Beta is even higher now than what it was on that earlier visit, or we would have had a hash cutoff, so the captures will fail low even more badly as they did before. So we might as well take an immediate fail low by returning the evaluation.

[brtzsnr]

After some thinking about this I am still puzzled as why you would want to do that. If you have a hash move you have had a hit on an entry containing a lower bound on the score. As you are in QS, any draft would be sufficient for a hash cutoff, so the reason that you don't take the cutoff can only be that the stored lower bound is smaller than beta.

I tested using the hashmove in QS recently with almost no Elo change. For some reason, I still included this patch.

Code: Select all

LTC
26100 @ 40/60+0.05
8049 - 7926 - 10125
ELO 1.64±3.30

In addition the current evaluation would be below beta, or you would have taken the stand-pat cutoff. In general non-captures do not increase the evaluation much, so you would expect the move to be refuted by stand pat of the opponent. So you would be searching a move that you don't expect to do any good, and that on a previous more elaborate search was not shown to do good enough. This seems a lot like a 'wild goose chase'. Which percentage of such moves does actually score above alpha?

In fact I would be inclined to act on the following consideration: the hash hit shows the position has been searched before, and the fact that a non-capture became hash move shows that none of the captures was any good. Beta is even higher now than what it was on that earlier visit, or we would have had a hash cutoff, so the captures will fail low even more badly as they did before. So we might as well take an immediate fail low by returning the evaluation.

This makes sense. I'll try the suggested approach: if the hash move is not violent, just stand pat.

[brtzsnr]

Here are two bad test positions. Zurichess needs QS depth 20 to completely solve these ones.

[d] rr4k1/bb2q3/p1n1p3/3p3p/1P1PnppN/P1NQ3P/3B1PP1/2RBR1K1 w - - 2 28

[d] 3rnbk1/2q5/p2r1ppp/1p3pP1/PP1n3P/2NB4/2PB1R1Q/4R1K1 b - - 1 28

[brtzsnr]

And another one. Feel free to check if these are pathological cases for your QS, too.

[d] r1bq1rk1/1p1n1pp1/2pb3p/p1Npp3/1PPPn3/P3PN2/3BBPPP/R2Q1RK1 b - - 1 13

[cdani]

Maybe you can try by limiting QS depth. I limit it to 5, and from 6th I search only recaptures.

[cdani]

After some thinking about this I am still puzzled as why you would want to do that. If you have a hash move you have had a hit on an entry containing a lower bound on the score. As you are in QS, any draft would be sufficient for a hash cutoff, so the reason that you don't take the cutoff can only be that the stored lower bound is smaller than beta.

In addition the current evaluation would be below beta, or you would have taken the stand-pat cutoff. In general non-captures do not increase the evaluation much, so you would expect the move to be refuted by stand pat of the opponent. So you would be searching a move that you don't expect to do any good, and that on a previous more elaborate search was not shown to do good enough. This seems a lot like a 'wild goose chase'. Which percentage of such moves does actually score above alpha?

In fact I would be inclined to act on the following consideration: the hash hit shows the position has been searched before, and the fact that a non-capture became hash move shows that none of the captures was any good. Beta is even higher now than what it was on that earlier visit, or we would have had a hash cutoff, so the captures will fail low even more badly as they did before. So we might as well take an immediate fail low by returning the evaluation.

In fact always was like this in Andscacs if I remember well, consequence of Andscacs being done from 0 and without knowing many things about engine development. At some point I tried to limit quiescence to grab only captures from hash, but this change was not good nor bad, so I simply didn't accept that change.

Later even Stockfish take this approach when I explained it. I think they accepted the patch as a simplification.

I know I'm not providing any logic argument about the subject. Will be interesting at least to do some findings on what is happening, when those quiet moves are being accepted and what are they contributing.

[brtzsnr]

These are rare cases nonetheless.

The reason I don't limit depth in QS is because depth 0 means the QS evaluation. Nodes hashed inside QS can later be used from the main search or from other hashes without instabilities or inaccuracies.

[Maarten Claessens]

This is the debug-output of WaDuuttie for the two positions:

Code: Select all

WaDuuttie> sb rr4k1/bb2q3/p1n1p3/3p3p/1P1PnppN/P1NQ3P/3B1PP1/2RBR1K1 w - - 2 28

WaDuuttie> qs
c3e4 -18 (45)
e1e4 bad
d3e4 bad
h3g4 -44 (134)
c3d5 bad
d1g4 bad
d2f4 -8 (144)
d3a6 bad
Quiesce: -8 / 14 (324 nodes)

WaDuuttie> sb 3rnbk1/2q5/p2r1ppp/1p3pP1/PP1n3P/2NB4/2PB1R1Q/4R1K1 b - - 1 28

WaDuuttie> qs
c7c3 bad
f6g5 102 (14)
h6g5 70 (4)
b5a4 8 (1)
d4c2 bad
Quiesce: 102 / 8 (20 nodes)

WaDuuttie>

Short explanation:
"c3e4 -18 (45)" : the score of capture c3e4 is -18 cp and 45 nodes are searched.
"e1e4 bad" : the capture e1e4 is bad and is not investigated.
"Quiesce: -8 / 14 (324 nodes)" : the final qs-score is -8, max qs-depth is 14 and in total 324 nodes are searched.

Hope this helps.