Senpai 3.0 by Fabien LETOUZEY is available!

[Xann]

Salut Fabien,
the games were run similar to an ICGA tournament, only without an extra wooden board - so each engine had its own computer, the game was operated manually.
Senpai was setup as an UCI engine in the Fritz 17 GUI.
In the PGN you can see the game from Senpai’s point of view: time used for each move, the expected move and the depth and eval. As you can see, Senpai behaves exactly as you’d expect from an engine that ponders. This includes sometimes moving instantly after the opponent makes the expected move.

Thanks, Peter.

I can only assume that Fritz is somehow simulating pondering behaviour, even though I wrote no such code. I would need to think more about it, but I am visualising two missing features:

1) in ponder-on games it makes sense to allocate more time overall, because part of searching will not be counted on our clock.
2) continue searching indefinitely during the opponent's turn, instead of stopping when an internal time limit is reached; we can stop later, when the opponent makes the move.

I am guessing that Fritz isn't doing that (the second one seems impossible, without engine support), and it would explain why time usage is too low.

To fix the symptoms that you are describing, I would need to implement pondering ... I don't think that they can appear in a ponder-off game.

Fabien.

[Frank Quisinsky]

Hi there,

Fabien sent Senpai 3.0.2.

Fabien wrote me by mail:
Graham reported technical problems, with log files. It appears that the testers allow engines to have small negative times on their clock (1 to 5 seconds); they call it 'overstep'. Negative times (even for the opponent) make Senpai 3.0.1 crash. This version fixes that.

I added the Senpai 3.0.2 files in Senpai directory on my older website.
https://www.amateurschach.de/main/_download.htm

Best
Frank

[RubiChess]

Crashing on negative time would probably be the better solution instead of playing (almost) random depth 1 move and losing the game instantly in many cases.

Code: Select all

andreas@andreas-asuslnx:~/schach/engines/_senpai-versions(1)/v3.0.2$ target/release/senpai_302
uci
id name Senpai 3.0.2
id author Fabien Letouzey
option name Hash type spin default 64 min 16 max 32768
option name Threads type spin default 1 min 1 max 64
option name Move Overhead type spin default 100 min 0 max 10000
option name Draw Score type spin default 0 min -100 max 100
option name UCI_Chess960 type check default false
uciok
position startpos
go wtime -10 winc 1000
info depth 1 seldepth 1 score cp 44 nodes 21 time 6 nps 3618 pv e2e3
info depth 1 seldepth 1 nodes 21 time 6 nps 3499
bestmove e2e3

Main problem is in ChessGUI used by Graham which is known for "losing" time > 1s per move at least on Graham's tourney machine. See https://github.com/official-stockfish/S ... 1614385254
This could be compensated by giving the engines an appropriate value for their Move Overhead option.
My guess is that Graham still doesn't do that.
Using this "1 to 5 seconds ... overstep" in the GUI (in the SF issue called "GUI's 5000ms grace overhead") is no solution for the problem. I tried to explain that in the issue but I fear that I failed.

Another example for CCRL ignoring recommendations of engine authors.

BTW. Cargo.toml still has old version 3.0.1.

[Graham Banks]

Crashing on negative time would probably be the better solution instead of playing (almost) random depth 1 move and losing the game instantly in many cases.

Code: Select all

andreas@andreas-asuslnx:~/schach/engines/_senpai-versions(1)/v3.0.2$ target/release/senpai_302
uci
id name Senpai 3.0.2
id author Fabien Letouzey
option name Hash type spin default 64 min 16 max 32768
option name Threads type spin default 1 min 1 max 64
option name Move Overhead type spin default 100 min 0 max 10000
option name Draw Score type spin default 0 min -100 max 100
option name UCI_Chess960 type check default false
uciok
position startpos
go wtime -10 winc 1000
info depth 1 seldepth 1 score cp 44 nodes 21 time 6 nps 3618 pv e2e3
info depth 1 seldepth 1 nodes 21 time 6 nps 3499
bestmove e2e3

Main problem is in ChessGUI used by Graham which is known for "losing" time > 1s per move at least on Graham's tourney machine. See https://github.com/official-stockfish/S ... 1614385254
This could be compensated by giving the engines an appropriate value for their Move Overhead option.
My guess is that Graham still doesn't do that.

1000ms as recommended by the SF developers.

Using this "1 to 5 seconds ... overstep" in the GUI (in the SF issue called "GUI's 5000ms grace overhead") is no solution for the problem. I tried to explain that in the issue but I fear that I failed.

Another example for CCRL ignoring recommendations of engine authors.

BTW. Cargo.toml still has old version 3.0.1.

[Xann]

Crashing on negative time would probably be the better solution instead of playing (almost) random depth 1 move and losing the game instantly in many cases.

In Graham's log files, the negative time was on the opponent's clock. I had to fix that.

[RubiChess]

This could be compensated by giving the engines an appropriate value for their Move Overhead option.
My guess is that Graham still doesn't do that.

1000ms as recommended by the SF developers.

Okay, apologize for the wrong accusation.

But the problems remain as long as you see negative (or even very small positive) go-times in your logs.
1000ms overhead may be okay for SF and its time management. From the logs mentioned in the issue we can see that GUI delay can be far bigger than 1000ms.
Engines without the option "Move overhead" (e.g. the opponent of Senpai in the mentioned game?) will run into the problem sooner or later and play random instant moves leading to useless games.
Main problem is the GUI.

Regards, Andreas

[Graham Banks]

But the problems remain as long as you see negative (or even very small positive) go-times in your logs.
1000ms overhead may be okay for SF and its time management. From the logs mentioned in the issue we can see that GUI delay can be far bigger than 1000ms.
Engines without the option "Move overhead" (e.g. the opponent of Senpai in the mentioned game?) will run into the problem sooner or later and play random instant moves leading to useless games.
Main problem is the GUI.

Regards, Andreas

I check my games to make sure that what you're worried about doesn't happen.
I've tried other GUIs in the past, but ChessGUI is the only one that suits all of my needs, primarily running all types of engines, utilizing features that Matthias specifically implemented at my request, and the ability to run seamless broadcasts.
Remember that TCEC once used ChessGUI as well.

Regards,
Graham.

[jshriver]

Maybe I've not dug deep enough but is the code available to compile? Most things I've come across end up on a Senpai 2.0 github.
If not is there a x86 bmi2 linux build available?

[Xann]

Maybe I've not dug deep enough but is the code available to compile? Most things I've come across end up on a Senpai 2.0 github.
If not is there a x86 bmi2 linux build available?

This version is only useful for people who are experiencing crashes. They are so specific that, if you are unsure, you don't need this version.

The code is in the 'src' directory, same place as the rest, and there is a 'compile.txt' file. Perhaps you don't have Rust installed on your machine.