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.
It's easier limit nodes than slow down a CPU enough to keep SF at a constant low NPS.
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.
Uri Blass wrote: ↑Mon Jan 20, 2020 6:53 am
The question is also if fixed nodes per move has to be exactly 18K nodes per move or maybe the engine is allowed to use at most 18K nodes per move at move 1 when nodes that it did not use can be used in the next move so with 18K nodes per move the engine can use
at most 18k*n nodes for the first n moves but it can use less than 18K nodes for part of the moves in order to be allowed to use more than 18K nodes in another part of the moves.
Yes, but then why not just use some microbullet time control that averages 18K nodes per move? Just let the engine decide by itself if it needs less or if it needs more. I'd expect that an engine at averages 18K nodes per move would greatly outperform a fixed one.
Response time of the engine starts becoming an issue at mini-micro-bullet.
And something I can always try afterwards.
I'll first test Stockfish against weaker chessboards to establish a baseline performance anyway.
If I do need to squeeze some ELO out of it, I'll try and see what I can do with my Raspberry Pi 3b.
Mephisto to UCI works and the emulator automatically adjusts its speed to my system so I only need to give it a 40/120 TC and will run and also leaves behind a log.
Bad thing is that unless the option is hidden somewhere I can't speed it up.
And the strongest Mephisto it offers is the 32bit version of Dallas iirc.
The other emulator works too and can be sped up enormously but I have to do everything by hand. Also I don't have an user manual for every engine so some are a pain the ass to use.
The Tasc ChessSystem R30 (and R40) both work fine and have an easy UI so if 18k SF somehow chews through the Mephisto engines I can still test by hand.
Will begin real testing very soon.
Here's one test game.
Will have to do some more testing because I don't think Mephisto-Amsterdam can properly use 40/120.
Looking at a chessboard wiki it could do 30s/move, 30 min/game, 60s/move and 60 min/game.
So I'll have to some more testing and maybe adjust TC for both.