It's easier limit nodes than slow down a CPU enough to keep SF at a constant low NPS.Ovyron wrote: ↑Mon Jan 20, 2020 4:49 am What is the meaning of "fixed nodes per move", though? Because when you force the engine to play like that, you're forcing it to abort the search on some random point of the current iteration, and then I'm not sure what's the best strategy to follow when choosing a move.
Suppose it's on the middle of the main move failing low, does it still play it and ignore the fail low? Or does it play instead a move that it knows it's currently better? (but that could be worse after resolving the fail low.) What if it's on the middle of an alternative move failing high? Does it still play the main move even though it currently has a score that is worse than the alternative? Or does it switch to the move failing high, even though after the fail high was resolved perhaps it finished worse than the other one?
What about ignoring all this and just playing the move that was known to be best at the end of the previous iteration? But this would waste nodes...
So I don't think engines are designed to abort the search and pick a move before the current iteration is over, and wonder if we'd get much better results if they were designed for fixed nodes per second in mind, and if it'd be more fruitful to test them at fixed depth.
Maybe adding a prime number counter in the SF code could do the trick but that might add other problems.
Nobody thinks fixed nodes is an ideal or perfect solution but it's a compromise (and an easy solution).
Most versions of SF do finish an iteration so it generally doesn't stop at 18000 nodes but a little higher. Sometimes at 19 kn for certain versions. Which is fine since it's a bit weaker than having a proper TC anyway.