Basic time control

[CMCanavessi]

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]

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

[killerducky]

@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]

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]

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]

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

[CMCanavessi]

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]

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

[jkiliani]

Why not simply let a playout setting override time control?

[CMCanavessi]

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]

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]

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]

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]

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]

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

[JackThomson2]

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

[CMCanavessi]

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]

Hope it gets merged soon in the official release!

[zz4032]

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]

@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]

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

[JackThomson2]

Yes, should use work correctly with multiple threads now.

[CMCanavessi]

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

[glinscott]

Thanks @JackThomson2!