Quiescence Search Performance

Discussion of chess software programming and technical issues.

Moderators: hgm, Dann Corbit, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
theturk1234
Posts: 52
Joined: Tue Jul 12, 2016 3:28 am

Re: Quiescence Search Performance

Post by theturk1234 » Fri Jul 29, 2016 4:30 am

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

User avatar
cdani
Posts: 2200
Joined: Sat Jan 18, 2014 9:24 am
Location: Andorra
Contact:

Re: Quiescence Search Performance

Post by cdani » Fri Jul 29, 2016 6:24 am

hgm wrote:
cdani wrote:* 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.

User avatar
hgm
Posts: 26578
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Quiescence Search Performance

Post by hgm » Fri Jul 29, 2016 8:51 am

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
Posts: 433
Joined: Fri Jan 16, 2015 3:02 pm
Contact:

Re: Quiescence Search Performance

Post by brtzsnr » Fri Jul 29, 2016 10:35 am

hgm wrote: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
hgm wrote: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
Posts: 433
Joined: Fri Jan 16, 2015 3:02 pm
Contact:

Re: Quiescence Search Performance

Post by brtzsnr » Sat Jul 30, 2016 7:20 am

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
Posts: 433
Joined: Fri Jan 16, 2015 3:02 pm
Contact:

Re: Quiescence Search Performance

Post by brtzsnr » Sat Jul 30, 2016 7:37 am

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

User avatar
cdani
Posts: 2200
Joined: Sat Jan 18, 2014 9:24 am
Location: Andorra
Contact:

Re: Quiescence Search Performance

Post by cdani » Sat Jul 30, 2016 7:54 am

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

User avatar
cdani
Posts: 2200
Joined: Sat Jan 18, 2014 9:24 am
Location: Andorra
Contact:

Re: Quiescence Search Performance

Post by cdani » Sat Jul 30, 2016 8:03 am

hgm wrote: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
Posts: 433
Joined: Fri Jan 16, 2015 3:02 pm
Contact:

Re: Quiescence Search Performance

Post by brtzsnr » Sat Jul 30, 2016 8:07 am

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
Posts: 106
Joined: Mon May 12, 2014 8:08 am
Location: Near Nijmegen

Re: Quiescence Search Performance

Post by Maarten Claessens » Sat Jul 30, 2016 8:13 am

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.
Nothing is unstable (Lawrence Krauss)

Post Reply