Depth dependent reduction threshold when full-depth re-search #6210
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.
Bench: 3035862
STC: https://tests.stockfishchess.org/tests/view/68894d577b562f5f7b73273b
LLR: 2.98 (-2.94,2.94) <0.00,2.00>
Total: 155072 W: 40651 L: 40150 D: 74271
Ptnml(0-2): 609, 18271, 39292, 18738, 626
LTC: https://tests.stockfishchess.org/tests/view/688c2705502b34dd5e71127a
LLR: 2.95 (-2.94,2.94) <0.50,2.50>
Total: 321012 W: 82891 L: 81995 D: 156126
Ptnml(0-2): 227, 34421, 90285, 35375, 198
This commit was generated using
qwen3-235b-a22b-thinking-2507:Prompt: https://rentry.co/iqtaoht7
Reasoning/thinking: https://rentry.co/wm6t9hye
Final response
Analysis and Improvement of Stockfish Search Code
I've selected the same search technique step as in example number 15, which targets the full-depth search section when Late Move Reductions (LMR) are skipped. This occurs for promising moves (captures, checks, killer moves, etc.) that would normally get full-depth searches but aren't the very first move.
Current Implementation Analysis
The current code handles this scenario as follows:
This code:
rexceeds certain thresholds (3200 or 4600)The key insight from Stockfish search development is that "Applying aggressive LMR at very low depths (e.g., starting from depth 2) can be surprisingly effective, potentially leading to deeper selective searches in key lines." The current implementation applies the same reduction thresholds regardless of search depth, but search behavior should be more aggressive at shallow depths where the search is faster and covering more ground is beneficial.
Critical Analysis
The current implementation has a significant limitation: it uses fixed thresholds (3200 and 4600) for depth reduction regardless of the current search depth. This is suboptimal because:
At very low depths (≤ 4), the search is extremely fast, and the marginal benefit of searching one more move often outweighs the marginal cost of slightly shallower search for each move.
The notes indicate that "search optimizations should be heavily focused on shallow depths, as the vast majority of nodes (over 99%) are at low depths (e.g., depth <= 10)."
The current approach doesn't leverage the opportunity to be more selective at low depths, which could improve move ordering for deeper iterations.
Research shows that "LMR is far more effective at cut nodes compared to PV nodes" and should be applied more aggressively when possible.
The proposed improvement introduces depth-dependent thresholds that lower the reduction barriers at low depths. This makes the search more aggressive with reductions specifically when depth is shallow (≤ 4), allowing the engine to examine more moves at these critical early search stages. This approach scales well with longer time controls because better early move ordering leads to more efficient deeper searches.
Final Patch
search.cpp:
Improved search.cpp:
Branch name: lmr_aggressive_at_low_depths_scaler