cutechess-cli disable/limit console output

[Desperado]

Hello everybody,

does someone know if it is possible to disable or to limit the console output from cutchess-cli. ( Maybe i overlooked it in the manual )

thx in advance.

Michael

[Daniel Shawul]

But how would you know the game result then ? AFAIK there is not an option to turn that off. Cutechess sends three lines per game, and if you suppress that ,say by sending to /dev/null, then you won't know the result. I am sure at some point I used a python script to pipe the debug file to and extract the 1-0s, while using CLOP or something. Maybe you should ask for the package that stockfish uses. It seems to have everything incorporated cutechess+clop+sprt+etc.
Edit: Ah..the pgn files can be used at least for calculating the elo result but probably not for CLOP tuning. So /dev/null it is.

[Rebel]

Perhaps the > parameter will do the job. Adding >output.txt stores the screen output to the textfile output.txt

[Desperado]

Hi,

well, thanks for answering.

I really intend to switch off the communication overhead. So redirecting
is not the idea. The reason is that i do some light speed experiments, which
in general only generate a movelist and pick a move. So, the communication seems to slow down the time a match runs
( at least i do have the impression ). Finally it simply looks like the communication cannot be turned off.

Anyway, thx a lot.

[lucasart]

Hi,

well, thanks for answering.

I really intend to switch off the communication overhead. So redirecting
is not the idea. The reason is that i do some light speed experiments, which
in general only generate a movelist and pick a move. So, the communication seems to slow down the time a match runs
( at least i do have the impression ). Finally it simply looks like the communication cannot be turned off.

Anyway, thx a lot.

My advice is:
- switch off all the useless UCI discussions between your engine and cutchess-cli: only send the bestmove command.
- redirect stdout to /dev/null

We could discuss endlessly about the various sources of lag (internal to cutechess-cli, due to pipe communication and task switching). But these discussions are pointless without measures. Here's a good measure:
- depth=1 tc=inf (the fastest possible *reproductible* search limit)
- measure by not redirecting, or by redirecting to a file, or by redirecting to /dev/null.

(you can also use another depth or a fixed node search, but the lower depth the better as it isolates the communication overhead the most).

[lucasart]

On another note, be careful about ultra-mega-fast testing. It is not uncommon (in fact very common) that a patch is:
- a clear regression at 10,000 nodes per move
- a clear improvement at 20,000 nodes per move
- a slight regression at 50,000 nodes per move
- unmeasurable at 10"+0.1"

That is typically why I never managed to get anything useful out of CLOP. You need to play so many games for it to converge properly that you end up playing these games at stupidly fast tc (not to mention the ridiculous overhead of having to restart cutechess-cli and the engines every time to play 1 game at a time, and parralelising in the python script)... and then you restest with your CLOP-timized values, and... surprise... it's a regression at proper time control...

[lucasart]

You have to get the result somwhow, so I suppose you'll ask cutechess-cli to output a PGN. Well I'm sure there's a considerable overhead in that too. In fact, it's quite likely that the best way is to not output a PGN and redirect cutechess-cli's stdout to a file, to that you get the result at the end of the file.