At first I thought it was just my imagination, but according to the “time” numbers in the logs LCZero is not searching for 30 seconds. The average search lasts only about 18 seconds. 16 seconds was the shortest I observed and the longest was 22. Weights files are not a factor, it happens with the smallest all the way up to the biggest.
Definitely not your imagination 
What I think happens is that at some point LcZero determine that it’s impossible to make any more progress in the time remaining so it just stops. Here’s a better explanation:
1 Like
Thanks for the link!
So it looks like LCZero is set by default to a mode designed to conserve time during engine matches.
However, there is an option that allows her to use the full 30 seconds for analysis, which is our only concern here at NCM?
(“There is a parameter that forces lc0 not to move early… --smart-pruning-factor … Set it to zero to achieve the effect you want.”)
It’s entirely possible that I’m not understanding this correctly, but I think that setting --smart-pruning-factor would only result in wasted cycles. Here’s the documentation I’m reading from https://lczero.org/play/flags/:
Do not spend time on the moves which cannot become bestmove given the remaining time to search. When no other move can overtake the current best, the search stops, saving the time. Values greater than 1 stop less promising moves from being considered even earlier. Values less than 1 causes hopeless moves to still have some attention. When set to 0, smart pruning is deactivated.
So, assuming the feature is working correctly, I think that it means that in your case, calculating for the extra 8 to 14 seconds wouldn’t affect the outcome?
If that’s the case, the benefit on NCM to having the search stop early is that it frees up the GPU servers faster to minimize the chance of calculations queuing.
I think “wasted cycles” depends on how you’re using the engine.
If you only care about the best move then the current setting makes perfect sense. Once the second best move can no longer overtake the best move, then every cycle after that moment IS wasted.
HOWEVER, if you want to know what the FOUR best moves are, then every last cycle matters.
At the speed your machines are running, in 10-15 seconds, the 2nd, 3rd and 4th picks can change significantly not only in their centipawn evals, but in the depth and nature of their variations. OR they may be replaced entirely by other moves.
IMHO, the current setting is best for engine matches, but not for analysis.
Aye, yes, very good point. I think you’re exactly right. What do you think about setting SmartPruningFactor to 0 when MultiPV > 1, and leaving it at the default otherwise?
Ah! Sounds like the big brain move to me.
Done! If MultiPV is > 1, we’re now sending setoption name SmartPruningFactor value 0 to the engine.
You won’t see this in the engine log because the change was implemented outside of NCM’s purview – inside of a Perl script that filters the engine’s I/O. (Stripping ANSI escape sequences and such.) We’ll get that fixed soon.
But you should notice the effects. Whenever MultiPV is > 1, the calculation should run for the entire think time, and you should see that reflected in the “time” UCI output values.