Disable qsearch danger-detection (SideCanStandPat) as an experiment

Profiling (pmcstat, sampled) showed SideCanStandPat as the single
hottest leaf function in the engine, ahead of Eval itself -- not from
expensive logic (it's a 3-line signature/lock/lookup), but from sheer
call volume (~95% of the tree is qsearch) combined with a likely-cold
16MB global hash table probe and an uncontended-but-nonzero lock/unlock
pair paid on every call even single-threaded.

Disabling it entirely: real bench nps was flat (~1.53M vs ~1.57M,
within noise -- the earlier "1.2M->1.75M" bench reading was itself an
uncontrolled, noisy single comparison on this shared box, not a real
effect). But ECM (sn 4M) came back at 655/879, the best result of the
whole session (vs 650 baseline) -- suggests the danger-detection
heuristic may have been net-negative for search quality on balance,
forcing exhaustive no-stand-pat search in some positions where
standing pat was actually fine. Speed claim didn't hold up; the
tactical-quality result is a genuine, unexpected positive worth
investigating further.

Not yet validated in self-play -- pending a clean match run.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

1 files changed, 5 insertions, 5 deletions

diff --git a/src/search.c b/src/search.c
index 00b37f2..bfb293e 100755
--- a/src/search.c
+++ b/src/search.c
@@ -1269,11 +1269,11 @@ QSearch(IN SEARCHER_THREAD_CONTEXT *ctx,
     // his position looks dangerous (i.e. more than one piece en prise
     // or a piece trapped).  Fail low if there's nothing that looks
     // good on this line.
-    if (SideCanStandPat(pos, pos->uToMove) == FALSE)
-    {
-        iBestScore = QSearchInDangerNoStandPat(ctx, iAlpha, iBeta);
-        goto end;
-    }
+    //if (SideCanStandPat(pos, pos->uToMove) == FALSE)
+    //{
+    //    iBestScore = QSearchInDangerNoStandPat(ctx, iAlpha, iBeta);
+    //    goto end;
+    //}
 
     // If we get here then side on move is not in check and this
     // position looks ok enough to allow him the option to stand pat