glinscott / leela-chess

**MOVED TO https://github.com/LeelaChessZero/leela-chess ** A chess adaption of GCP's Leela Zero
http://lczero.org
GNU General Public License v3.0
760 stars 298 forks source link

Basic time control #123

Closed CMCanavessi closed 6 years ago

CMCanavessi commented 6 years ago

Could we implement at least some super basic time control? For example, if you set a game to be 40/40, then it could calculate that it needs 1 minute per move, and then move exactly at 55 or 57 seconds, just to be sure there's no time losses. Or if you set an increment, it could just do the same as above, and then after the time is gone, play only with the increment... I don't know, but it's needed asap imho, specially for testers.

JackThomson2 commented 6 years ago

My C++ is very rusty, but I'll look at implementing something now.

killerducky commented 6 years ago

@JackThomson2 LZGo has a TimeControl.cpp class, it should be a good starting point. Note that Fischer is a bit similar to byo-yomi. In LZGo the TimeControl is a member of one of the Board/State classes, which is a member of GTP. In LZChess those are similar to Position.cpp and UCI.cpp.

JackThomson2 commented 6 years ago

I've been working on porting over the work from Stockfish, getting there :+1:

edit: Stockfish's timing is now working, a lot of testing needed now :)

CMCanavessi commented 6 years ago

Wow, that's awesome. If we get a new lczero.exe from appveyor, does it already contains these modifications?

Also another thing, when we use time control, we should not limit the playouts. Both options should be mutually exclusive.

JackThomson2 commented 6 years ago

Ive taken the approach of using the number of playouts, unless uci specifies a time control.

CMCanavessi commented 6 years ago

Sounds logical. We should be careful not to mess with the training games. I was thinking of maybe implementing a flag, something like --train for lczero to behave exactly as it is now, and if that flag is not set, then Time Control would be enabled.

JackThomson2 commented 6 years ago

Looking good testing vs stockfish level 0 using a time control Leela made easy work of stockfish :1st_place_medal:

jkiliani commented 6 years ago

Why not simply let a playout setting override time control?

CMCanavessi commented 6 years ago

Yep, that could work too. I don't know how "client" calls "lczero" and how the training games are played. Is there a time control specified on those games? tc=inf maybe? Is lczero called specifically with --playouts=800 or no option and just defaults to 800?

jjoshua2 commented 6 years ago

having a --train could help as more features diverge, like if train gets early resign/draw/TB adjudication that UCI supported, or if UCI version gets TB/time features that aren't wanted in training even though they would add elo.

killerducky commented 6 years ago

LZGo: Server passes -v3200 (a recent change from -p1600) to client (autogtp). Client passes on -v3200 to LZGo. Client also sends a GTP command to use infinite thinking time, overriding LZGo's default of 1 minute per move. LZGo allows both -p/-v and timecontrol. Whichever is reached first causes the search to stop.

LZChess: 800 is the default coded into LZChess binary. Server/Client don't change this.

I think it's more flexible to have the server pass as much as possible with command line options, and the client to pass them directly. Then if we decide to change something the server can do it without updating clients. For example LZGo recently changed the resign threshold server side, clients and LZGo just obeyed the new command line.

(BTW an enhancement for LZGo is to warn the user if they specify -p/-v but the timecontrol overrides it. They probably won't realize it. I haven't gotten around to doing this).

JackThomson2 commented 6 years ago

This was my thought of having the time controls override the default, this means the client will behave exactly the same as before until uci passes in time controls.

JackThomson2 commented 6 years ago

As I mentioned my C++ is very rusty, if someone would like to review this as far as I can tell it is all working for me. https://github.com/JackThomson2/leela-chess

CMCanavessi commented 6 years ago

Do you have a binary? I can't compile here, but can test if some1 provides a .exe

JackThomson2 commented 6 years ago

Can try the binary from here if you like: https://ci.appveyor.com/project/glinscott/leela-chess/build/80/job/juo4hh2fqngsktp9/artifacts

CMCanavessi commented 6 years ago

Did a quick test in Arena and it looks to be working great!!! I tested at 40/40 (and the 1st couple of moves were thought for around 70 seconds). Then I changed it to 40/1 and it was faster. Then I tried 5 seconds + 0.5 seconds, and it was working ok.

Awesome job. This will be great for the end user, as it doesn't have to worry or care about playouts at all, it's all transparent and behaves like a normal engine, the more time you give it, the stronger it becomes!

CMCanavessi commented 6 years ago

Hope it gets merged soon in the official release!

zz4032 commented 6 years ago

That's great! With fischer time or time/game setting we even get a basic time management where LCZero spends more time in the opening phase and less in the endgame, is that correct?

JackThomson2 commented 6 years ago

@zz4032 & @CMCanavessi A new version is available to try here: https://ci.appveyor.com/project/glinscott/leela-chess/build/92/job/sfjkehvifusayipg/artifacts should see far superior Nodes per second when compared to before :+1: equal with normal

CMCanavessi commented 6 years ago

Is that a fix to the "threads" issue as reported in the other discussion?

JackThomson2 commented 6 years ago

Yes, should use work correctly with multiple threads now.

CMCanavessi commented 6 years ago

Testing it right now with Gen 9 network, at 40/40... will report later.

glinscott commented 6 years ago

Thanks @JackThomson2!