mirror of
https://github.com/HChaZZY/Stockfish.git
synced 2025-12-20 00:56:39 +08:00
Small code tidy up and test results
When testing at 1'+0" time control results are still reasonably good. We have made two sessions on two different PC. After 840 games Mod - Orig: +221 -194 =425 +10 ELO (two CPU) After 935 games Mod - Orig: +246 -222 =467 +9 ELO (single CPU) So it seems that with fast CPU and/or longer time controls benefits of the patch are a bit reduced. This could be due to the fact that only 3% of nodes are pruned by razoring at depth one and these nodes are very swallow ones, mostly get pruned anyway with only a slightly additional cost, even without performing any do_move() call. Another reason is that sometime (0,3%% of cases) a possible good move is missed typically in positions when moving side gives check, as example in the following one 3r2k1/pbpp1nbp/1p6/3P3q/6RP/1P4P1/P4Pb1/3Q2K1 w - - The winning move Rxg7+ is missed. Bottom line is that patch seems good for blitz times, perhaps also for longer times. We should test against a third engine (Toga ?) to have a final answer regarding this new setup. Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This commit is contained in:
@@ -128,10 +128,6 @@ namespace {
|
||||
o["Selective Plies"] = Option(7, 0, 10);
|
||||
o["Futility Pruning (Main Search)"] = Option(true);
|
||||
o["Futility Pruning (Quiescence Search)"] = Option(true);
|
||||
//o["Futility Margin (Quiescence Search)"] = Option(50, 0, 1000);
|
||||
//o["Futility Margin Scale Factor (Main Search)"] = Option(100, 0, 1000);
|
||||
//o["Maximum Razoring Depth"] = Option(3, 0, 4);
|
||||
//o["Razoring Margin"] = Option(300, 150, 600);
|
||||
o["LSN filtering"] = Option(true);
|
||||
o["LSN Time Margin (sec)"] = Option(4, 1, 10);
|
||||
o["LSN Value Margin"] = Option(200, 100, 600);
|
||||
|
||||
Reference in New Issue
Block a user