Limit the researching at same depth. #4104
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If the elapsed time is close to the available time, the time management thread can signal that the next iterations should be searched at the same depth (Threads.increaseDepth = false). While the rootDepth increases, the adjustedDepth is kept constant with the searchAgainCounter. In exceptional cases, when threading is used and the master thread, which controls the time management, signals to not increaseDepth, but by itself takes a long time to finish the iteration, the helper threads can search repeatedly a the same depth. This search finishes more and more quickly, leading to helper threads that report a rootDepth of MAX_DEPTH (245). The latter is not optimal as it is confusing for the user, stops search on these threads, and leads to an incorrect bias in the thread voting scheme. Probably with only a small impact on strength. This behavior was observed almost two years ago, see official-stockfish#2717 This patch fixes official-stockfish#2717 by ensuring the effective depth increases at once every four iterations, even in increaseDepth is false. Depth 245 searches (for non-trivial positions) were indeed absent with this patch, but frequent with master in the tests below: https://discord.com/channels/435943710472011776/813919248455827515/994872720800088095 Total pgns: 2173 Base: 2867 Patch: 0 it passed non-regression testing in various setups: SMP STC: https://tests.stockfishchess.org/tests/view/62bfecc96178ffe6394ba036 LLR: 2.94 (-2.94,2.94) <-2.25,0.25> Total: 37288 W: 10171 L: 10029 D: 17088 Ptnml(0-2): 75, 3777, 10793, 3929, 70 SMP LTC: https://tests.stockfishchess.org/tests/view/62c08f6f49b62510394be066 LLR: 2.94 (-2.94,2.94) <-2.25,0.25> Total: 190568 W: 52125 L: 52186 D: 86257 Ptnml(0-2): 70, 17854, 59504, 17779, 77 LTC: https://tests.stockfishchess.org/tests/view/62c08b6049b62510394bdfb6 LLR: 2.96 (-2.94,2.94) <-2.25,0.25> Total: 48120 W: 13204 L: 13083 D: 21833 Ptnml(0-2): 54, 4458, 14919, 4571, 58 Special thanks to miguel-I, Disservin, ruicoelhopedro and others for analysing the problem, the data, and coming up with the key insight, needed to fix this longstanding issue. Bench: 5182295
PikaCat-OuO
pushed a commit
to official-pikafish/Pikafish
that referenced
this pull request
Oct 7, 2022
If the elapsed time is close to the available time, the time management thread can signal that the next iterations should be searched at the same depth (Threads.increaseDepth = false). While the rootDepth increases, the adjustedDepth is kept constant with the searchAgainCounter. In exceptional cases, when threading is used and the master thread, which controls the time management, signals to not increaseDepth, but by itself takes a long time to finish the iteration, the helper threads can search repeatedly at the same depth. This search finishes more and more quickly, leading to helper threads that report a rootDepth of MAX_DEPTH (245). The latter is not optimal as it is confusing for the user, stops search on these threads, and leads to an incorrect bias in the thread voting scheme. Probably with only a small impact on strength. This behavior was observed almost two years ago, see official-stockfish/Stockfish#2717 This patch fixes #2717 by ensuring the effective depth increases at once every four iterations, even in increaseDepth is false. Depth 245 searches (for non-trivial positions) were indeed absent with this patch, but frequent with master in the tests below: https://discord.com/channels/435943710472011776/813919248455827515/994872720800088095 Total pgns: 2173 Base: 2867 Patch: 0 it passed non-regression testing in various setups: SMP STC: https://tests.stockfishchess.org/tests/view/62bfecc96178ffe6394ba036 LLR: 2.94 (-2.94,2.94) <-2.25,0.25> Total: 37288 W: 10171 L: 10029 D: 17088 Ptnml(0-2): 75, 3777, 10793, 3929, 70 SMP LTC: https://tests.stockfishchess.org/tests/view/62c08f6f49b62510394be066 LLR: 2.94 (-2.94,2.94) <-2.25,0.25> Total: 190568 W: 52125 L: 52186 D: 86257 Ptnml(0-2): 70, 17854, 59504, 17779, 77 LTC: https://tests.stockfishchess.org/tests/view/62c08b6049b62510394bdfb6 LLR: 2.96 (-2.94,2.94) <-2.25,0.25> Total: 48120 W: 13204 L: 13083 D: 21833 Ptnml(0-2): 54, 4458, 14919, 4571, 58 Special thanks to miguel-I, Disservin, ruicoelhopedro and others for analysing the problem, the data, and coming up with the key insight, needed to fix this longstanding issue. closes official-stockfish/Stockfish#4104 Bench: 5182295 (cherry picked from commit 2e02dd7)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If the elapsed time is close to the available time, the time management thread can signal that the next iterations should be searched at the same depth (Threads.increaseDepth = false). While the rootDepth increases, the adjustedDepth is kept constant with the searchAgainCounter.
In exceptional cases, when threading is used and the master thread, which controls the time management, signals to not increaseDepth, but by itself takes a long time to finish the iteration, the helper threads can search repeatedly a the same depth. This search finishes more and more quickly, leading to helper threads that report a rootDepth of MAX_DEPTH (245). The latter is not optimal as it is confusing for the user, stops search on these threads, and leads to an incorrect bias in the thread voting scheme. Probably with only a small impact on strength.
This behavior was observed almost two years ago,
see #2717
This patch fixes #2717 by ensuring the effective depth increases at once every four iterations,
even in increaseDepth is false.
Depth 245 searches (for non-trivial positions) were indeed absent with this patch,
but frequent with master in the tests below:
https://discord.com/channels/435943710472011776/813919248455827515/994872720800088095
Total pgns: 2173
Base: 2867
Patch: 0
it passed non-regression testing in various setups:
SMP STC:
https://tests.stockfishchess.org/tests/view/62bfecc96178ffe6394ba036
LLR: 2.94 (-2.94,2.94) <-2.25,0.25>
Total: 37288 W: 10171 L: 10029 D: 17088
Ptnml(0-2): 75, 3777, 10793, 3929, 70
SMP LTC:
https://tests.stockfishchess.org/tests/view/62c08f6f49b62510394be066
LLR: 2.94 (-2.94,2.94) <-2.25,0.25>
Total: 190568 W: 52125 L: 52186 D: 86257
Ptnml(0-2): 70, 17854, 59504, 17779, 77
LTC:
https://tests.stockfishchess.org/tests/view/62c08b6049b62510394bdfb6
LLR: 2.96 (-2.94,2.94) <-2.25,0.25>
Total: 48120 W: 13204 L: 13083 D: 21833
Ptnml(0-2): 54, 4458, 14919, 4571, 58
Special thanks to miguel-I, Disservin, ruicoelhopedro and others for analysing the problem,
the data, and coming up with the key insight, needed to fix this longstanding issue.
Bench: 5182295