Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tweak double singular condition (Topo's patch) #3714

Closed

Conversation

snicolet
Copy link
Member

This is a combinaison of three commits:

  • introducing a class to calculate running averages
  • an algorithm to calm down the search in search explosions
  • a tweak in the double singular condition (Topo's patch)

@vondele I have kept the commit separated, tell me if you prefer that I squash them.

snicolet added a commit to snicolet/Stockfish that referenced this pull request Sep 23, 2021
This patch relax a little bit the condition for doubly singular moves
(ie moves that are so forced that we think that they deserve a local
double extension of the search). We lower the margin and allow up to
six such double extensions in the path between the root and the critical
node.

Original idea by Siad Daboul (@TopoIogist) in PR #3709

STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 33048 W: 8458 L: 8236 D: 16354
Ptnml(0-2): 120, 3701, 8660, 3923, 120
https://tests.stockfishchess.org/tests/view/614b24347bdc23e77ceb88fe

LTC:
LLR: 2.95 (-2.94,2.94) <0.50,3.50>
Total: 54176 W: 13712 L: 13406 D: 27058
Ptnml(0-2): 36, 5653, 15399, 5969, 31
https://tests.stockfishchess.org/tests/view/614b3b727bdc23e77ceb8911

closes official-stockfish/Stockfish#3714

Bench: 5792377
@snicolet snicolet force-pushed the search_explosion_PR2 branch from 5866dec to 2017164 Compare September 23, 2021 09:48
A class to calculate a running average of a series of values,
generalizing the ttHitAverage variable we already have in code.
For efficiency, all computations are done with integers. The
implementation uses an exponential moving average of period 4096
and resolution 1/1024.

See official-stockfish/Stockfish#3714

No functional change
This patch detects some search explosions due to double extensions in
our search algorithm which can happen in some pathological positions,
and takes measure to ensure progress even in these pathological situations.

While a small number of double extensions can be useful during search
(for example to resolve a tactical sequence), a sustained regime of
double extensions leads to search explosion and a non-finishing search.
See the discussion in official-stockfish/Stockfish#3544
and the issue official-stockfish/Stockfish#3532 .

The implemented algorithm is as follows:

a) at each node during search, store the current depth in the stack.
   Double extensions are by definition levels of the stack where the
   depth at ply N is strictly higher than depth at ply N-1.

b) during search, calculate for each thread a running average of the
   number of double extensions in the last 4096 visited nodes.

c) if one thread has more than 2% of double extensions for a sustained
   period of time (6 millions consecutive nodes, or about 4 seconds on
   my iMac), we decide that this thread is in an explosion state and
   we calm down this thread by preventing it to do any double extension
   for the next 6 millions nodes.

-----------

Example where the patch solves a search explosion:

```
./stockfish
ucinewgame
position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130
go infinite
```

This algorithm does not affect search in normal, non-pathological positions.
We verified that usual bench is unchanged up to depth 20 at least, for instance,
and that the node numbers are unchanged for a search of the starting position
at depth 32.

-------------

See official-stockfish/Stockfish#3714

Bench: 5575265
This patch relax a little bit the condition for doubly singular moves
(ie moves that are so forced that we think that they deserve a local
double extension of the search). We lower the margin and allow up to
six such double extensions in the path between the root and the critical
node.

Original idea by Siad Daboul (@TopoIogist) in PR #3709

STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 33048 W: 8458 L: 8236 D: 16354
Ptnml(0-2): 120, 3701, 8660, 3923, 120
https://tests.stockfishchess.org/tests/view/614b24347bdc23e77ceb88fe

LTC:
LLR: 2.95 (-2.94,2.94) <0.50,3.50>
Total: 54176 W: 13712 L: 13406 D: 27058
Ptnml(0-2): 36, 5653, 15399, 5969, 31
https://tests.stockfishchess.org/tests/view/614b3b727bdc23e77ceb8911

closes official-stockfish/Stockfish#3714

Bench: 5792377
@snicolet snicolet force-pushed the search_explosion_PR2 branch from 2017164 to d2663ba Compare September 23, 2021 09:52
@vondele
Copy link
Member

vondele commented Sep 23, 2021

@snicolet yes, please squash with a single commit message.

Looks nice, hopefully this fixes the issue for real.

One minor nit, I would rename now - thisThread->lastNormalTime to nodesNow - thisThread->nodesLastNormal otherwise the 6000000 is confusing.

snicolet added a commit that referenced this pull request Sep 23, 2021
This patch detects some search explosions (due to double extensions in
search.cpp) which can happen in some pathological positions, and takes
measures to ensure progress in search even for these pathological situations.

While a small number of double extensions can be useful during search
(for example to resolve a tactical sequence), a sustained regime of
double extensions leads to search explosion and a non-finishing search.
See the discussion in #3544
and the issue #3532 .

The implemented algorithm is the following:

a) at each node during search, store the current depth in the stack.
   Double extensions are by definition levels of the stack where the
   depth at ply N is strictly higher than depth at ply N-1.

b) during search, calculate for each thread a running average of the
   number of double extensions in the last 4096 visited nodes.

c) if one thread has more than 2% of double extensions for a sustained
   period of time (6 millions consecutive nodes, or about 4 seconds on
   my iMac), we decide that this thread is in an explosion state and
   we calm down this thread by preventing it to do any double extension
   for the next 6 millions nodes.

To calculate the running averages, we also introduced a auxiliary class
generalizing the computations of ttHitAverage variable we already had in
code. The implementation uses an exponential moving average of period 4096
and resolution 1/1024, and all computations are done with integers for
efficiency.

-----------

Example where the patch solves a search explosion:

```
   ./stockfish
   ucinewgame
   position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130
   go infinite
```

This algorithm does not affect search in normal, non-pathological positions.
We verified, for instance, that the usual bench is unchanged up to depth 20
at least, and that the node numbers are unchanged for a search of the starting
position at depth 32.

-------------

See #3714

Bench: 5575265
@snicolet snicolet closed this in ff3fa0c Sep 23, 2021
@snicolet
Copy link
Member Author

Merged via 73018a0 and ff3fa0c

Joachim26 pushed a commit to Joachim26/StockfishNPS that referenced this pull request Mar 28, 2023
This patch detects some search explosions (due to double extensions in
search.cpp) which can happen in some pathological positions, and takes
measures to ensure progress in search even for these pathological situations.

While a small number of double extensions can be useful during search
(for example to resolve a tactical sequence), a sustained regime of
double extensions leads to search explosion and a non-finishing search.
See the discussion in official-stockfish#3544
and the issue official-stockfish#3532 .

The implemented algorithm is the following:

a) at each node during search, store the current depth in the stack.
   Double extensions are by definition levels of the stack where the
   depth at ply N is strictly higher than depth at ply N-1.

b) during search, calculate for each thread a running average of the
   number of double extensions in the last 4096 visited nodes.

c) if one thread has more than 2% of double extensions for a sustained
   period of time (6 millions consecutive nodes, or about 4 seconds on
   my iMac), we decide that this thread is in an explosion state and
   we calm down this thread by preventing it to do any double extension
   for the next 6 millions nodes.

To calculate the running averages, we also introduced a auxiliary class
generalizing the computations of ttHitAverage variable we already had in
code. The implementation uses an exponential moving average of period 4096
and resolution 1/1024, and all computations are done with integers for
efficiency.

-----------

Example where the patch solves a search explosion:

```
   ./stockfish
   ucinewgame
   position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130
   go infinite
```

This algorithm does not affect search in normal, non-pathological positions.
We verified, for instance, that the usual bench is unchanged up to depth 20
at least, and that the node numbers are unchanged for a search of the starting
position at depth 32.

-------------

See official-stockfish#3714

Bench: 5575265
Joachim26 pushed a commit to Joachim26/StockfishNPS that referenced this pull request Mar 28, 2023
This patch relax a little bit the condition for doubly singular moves
(ie moves that are so forced that we think that they deserve a local
double extension of the search). We lower the margin and allow up to
six such double extensions in the path between the root and the critical
node.

Original idea by Siad Daboul (@TopoIogist) in PR official-stockfish#3709

Tested with the previous commit:

passed STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 33048 W: 8458 L: 8236 D: 16354
Ptnml(0-2): 120, 3701, 8660, 3923, 120
https://tests.stockfishchess.org/tests/view/614b24347bdc23e77ceb88fe

passed LTC:
LLR: 2.95 (-2.94,2.94) <0.50,3.50>
Total: 54176 W: 13712 L: 13406 D: 27058
Ptnml(0-2): 36, 5653, 15399, 5969, 31
https://tests.stockfishchess.org/tests/view/614b3b727bdc23e77ceb8911

closes official-stockfish#3714

Bench: 5792377
@snicolet snicolet added the to be merged Will be merged shortly label Aug 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
to be merged Will be merged shortly
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants