From 2c5dfb312205de03239cb15e79b501789c4cd067 Mon Sep 17 00:00:00 2001 From: Joost VandeVondele Date: Sat, 10 Mar 2018 10:35:10 +0100 Subject: [PATCH] Assign improving only once Avoid duplicated code after recent commit "Use evaluation trend to adjust futility margin". We initialize the improving variable to true in the check case, which allows to avoid redundant code in the general case. Tested for speed by snicolet, patch seems about 0.4% faster. No functional change. Note: initializing the improving variable to false in the check case was tested as a functional change, ending yellow in both STC and LTC. This change is not included in the commit, but it is an interesting result that could become part of a future patch about improving or LMR. Reference of the LTC yellow test: http://tests.stockfishchess.org/tests/view/5aa131560ebc590297cb636e --- src/search.cpp | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/src/search.cpp b/src/search.cpp index 832501f2..98e3e945 100644 --- a/src/search.cpp +++ b/src/search.cpp @@ -654,6 +654,7 @@ namespace { if (inCheck) { ss->staticEval = eval = VALUE_NONE; + improving = true; goto moves_loop; } else if (ttHit) @@ -678,7 +679,6 @@ namespace { } improving = ss->staticEval >= (ss-2)->staticEval - /* || ss->staticEval == VALUE_NONE Already implicit in the previous condition */ ||(ss-2)->staticEval == VALUE_NONE; if (skipEarlyPruning || !pos.non_pawn_material(pos.side_to_move())) @@ -816,9 +816,6 @@ moves_loop: // When in check, search starts from here MovePicker mp(pos, ttMove, depth, &thisThread->mainHistory, &thisThread->captureHistory, contHist, countermove, ss->killers); value = bestValue; // Workaround a bogus 'uninitialized' warning under gcc - improving = ss->staticEval >= (ss-2)->staticEval - /* || ss->staticEval == VALUE_NONE Already implicit in the previous condition */ - ||(ss-2)->staticEval == VALUE_NONE; singularExtensionNode = !rootNode && depth >= 8 * ONE_PLY -- 2.39.2