Merge Joona's increased static null pruning

The idea is to fail high more easily in static
null test if in the parent node we are already
very deep in the move list, so the propability
to fail high there is very low.

[edit: I have slightly changed the functionality
moving

ss->futilityMoveCount = moveCount;

At the end of the pruning code, this should not affect
ELO in anyway, but makes code more natural and logic]

Test with SPRT is good at 15+0.05
LLR: 2.96 (-2.94,2.94)
Total: 50653 W: 10024 L: 9780 D: 30849

And at 60+0.05
LLR: 2.97 (-2.94,2.94)
Total: 40799 W: 7227 L: 6921 D: 26651

bench: 4530093

diff --git a/src/platform.h b/src/platform.h
index 36494c135022bcc0d6bd0a747dce5b35aef01710..ad02575bc4b983d207543252049759816e39f21f 100644 (file)
--- a/src/platform.h
+++ b/src/platform.h
@@ -40,6 +40,7 @@ typedef unsigned __int64 uint64_t;
 
 #else
 #  include <inttypes.h>
+#  include <unistd.h>  // Used by sysconf(_SC_NPROCESSORS_ONLN)
 #endif
 
 #if !defined(_WIN32) && !defined(_WIN64) // Linux - Unix

diff --git a/src/search.cpp b/src/search.cpp
index 267f5f8f4c64c87fbacc15f9184a16242dbcd394..0e68178147c7b2cbba34845c89e57218e6ea9b86 100644 (file)
--- a/src/search.cpp
+++ b/src/search.cpp
@@ -643,10 +643,10 @@ namespace {
         && !ss->skipNullMove
         &&  depth < 4 * ONE_PLY
         && !inCheck
-        &&  eval - futility_margin(depth, (ss-1)->futMc) >= beta
+        &&  eval - futility_margin(depth, (ss-1)->futilityMoveCount) >= beta
         &&  abs(beta) < VALUE_MATE_IN_MAX_PLY
         &&  pos.non_pawn_material(pos.side_to_move()))
-        return eval - futility_margin(depth, (ss-1)->futMc);
+        return eval - futility_margin(depth, (ss-1)->futilityMoveCount);
 
     // Step 8. Null move search with verification search (is omitted in PV nodes)
     if (   !PvNode
@@ -806,6 +806,7 @@ split_point_start: // At split points actual search starts from here
                         << " currmovenumber " << moveCount + PVIdx << sync_endl;
       }
 
+      ss->futilityMoveCount = 0;
       ext = DEPTH_ZERO;
       captureOrPromotion = pos.is_capture_or_promotion(move);
       givesCheck = pos.move_gives_check(move, ci);
@@ -852,8 +853,6 @@ split_point_start: // At split points actual search starts from here
       // Update current move (this must be done after singular extension search)
       newDepth = depth - ONE_PLY + ext;
 
-      ss->futMc = 0;
-
       // Step 13. Futility pruning (is omitted in PV nodes)
       if (   !PvNode
           && !captureOrPromotion
@@ -876,8 +875,6 @@ split_point_start: // At split points actual search starts from here
           // Value based pruning
           // We illogically ignore reduction condition depth >= 3*ONE_PLY for predicted depth,
           // but fixing this made program slightly weaker.
-          ss->futMc = moveCount;
-
           Depth predictedDepth = newDepth - reduction<PvNode>(depth, moveCount);
           futilityValue =  ss->staticEval + ss->evalMargin + futility_margin(predictedDepth, moveCount)
                          + Gain[pos.piece_moved(move)][to_sq(move)];
@@ -904,6 +901,10 @@ split_point_start: // At split points actual search starts from here
 
               continue;
           }
+
+          // We have not pruned the move that will be searched, but remember how
+          // far in the move list we are to be more aggressive in the child node.
+          ss->futilityMoveCount = moveCount;
       }
 
       // Check for legality only before to do the move

diff --git a/src/search.h b/src/search.h
index 2300c76271cc7c85a0d9d7e8bda732b9ba353e20..b4fb26ae72b9bee3b1bd80f1bfd225e12e654518 100644 (file)
--- a/src/search.h
+++ b/src/search.h
@@ -47,7 +47,7 @@ struct Stack {
   Value staticEval;
   Value evalMargin;
   int skipNullMove;
-  int futMc;
+  int futilityMoveCount;
 };