Re: Trying out the Leela Hybrid engine (NN with AB)
Posted: Thu Feb 21, 2019 4:03 am
Great thanks! I only test with CPU. Have used McCain X1 as AuxEngine. No more tactical mistakes to see from Leela.
Computer Chess Club
https://talkchess.com/
Go movetime let SF NOT decide to spend more or less time depending on the position... go movetime means, SF moves, when the time specified with that parameter is over...KillerDucky wrote: ↑Tue Feb 19, 2019 9:59 pm
Currently it runs SF using "go depth N" where N is a parameter. Would it be better to maybe use "go movetime N"? Where SF could decide to spend more or less time depending on the position?
SF doesn't decide how much time to spend for a given position, neither with movetime nor with fixed depth. Time management doesn't become a part of the equation in either case.pohl4711 wrote: ↑Thu Feb 21, 2019 12:16 pmGo movetime let SF NOT decide to spend more or less time depending on the position... go movetime means, SF moves, when the time specified with that parameter is over...
That would be definitly better a better solution, because a fix movetime will lead to much higher search-depths in the endgame, than a fix depth-parameter!
At the moment, I have no free PC, sorry. I had Komodo 12.3 as AuxEngine. It worked without any problems with ponder off in an engine-match in Fritz16, so the AuxengineOptions were definitly correct (Threads=1, Hash=1024). When ponder is set to on (in Fritz 16), Leelafish crashes, when it is pondering and the opponent engine plays its move and Leelafish should switch from pondering to thinking - caused an exception.KillerDucky wrote: ↑Thu Feb 21, 2019 5:29 pm pohl4711, please set LogFile to leelafish.log and send me it on my github issues. I can't debug crashes without logfiles.
The most common problem wrong AuxEngineOptions, please make sure you have the right format (no quotes, I saw several people doing that). If it's wrong you should see a line with "auxengine.cc:" plus an error message from the AuxEngine.
It seems there is no UCI standard for reporting errors back to the user? Maybe I could output a uci info string with an error message? Anyone have suggestions for error reporting?
Insomuch as the defaults are balanced for 1 thread, using more threads will reach the same depth faster, and thus have empty queues too often. So with more threads it should be necessary either to increase the default depth or decrease the number of nodes that launches a new search to the queue. You can see queue size in the logging if you put a log file name in that uci option, but it's quite difficult to optimize this way.yanquis1972 wrote: ↑Thu Feb 21, 2019 11:26 pm using 3 threads for SFdev as aux engine, 1024MB hash, everything else default.
Yes, you need to raise SD or ST when you increase threads. It is difficult to optimize by hand as far a I can tell, but on the other hand this is a magnificent first step!jjoshua2 wrote: ↑Fri Feb 22, 2019 1:12 amInsomuch as the defaults are balanced for 1 thread, using more threads will reach the same depth faster, and thus have empty queues too often. So with more threads it should be necessary either to increase the default depth or decrease the number of nodes that launches a new search to the queue. You can see queue size in the logging if you put a log file name in that uci option, but it's quite difficult to optimize this way.yanquis1972 wrote: ↑Thu Feb 21, 2019 11:26 pm using 3 threads for SFdev as aux engine, 1024MB hash, everything else default.