Cute Chess 0.9.4 released

[hgm]

Well, then I don't understand why you are making such a fuss. I merely pointed out that the 'weight' of the GUI wouldn't affect the tourney result, and thus could't be measured by it. Especially not if you leave one core for exclusive use by the GUI, so that it could consume CPU like mad and the engines still would not feel it. Then it could be very heavy weight indeed, and you still would not notice it.

I am perfectly happy to leave it at that conclusion. That was actually already my intention when I first mentioned it.

[PaulieD]

Well, then I don't understand why you are making such a fuss. I merely pointed out that the 'weight' of the GUI wouldn't affect the tourney result, and thus could't be measured by it. Especially not if you leave one core for exclusive use by the GUI, so that it could consume CPU like mad and the engines still would not feel it. Then it could be very heavy weight indeed, and you still would not notice it.

I am perfectly happy to leave it at that conclusion. That was actually already my intention when I first mentioned it.

I simply stated the results of my tourneys and seeing a difference between 0.9.3 and 0.9.4 stated that. No fuss.

[hgm]

So it would appear the CuteChessGUI 0.9.4 is "lightweight" also.

....

"Out" also seems to have a different meaning with you...

[hgm]

A wise choice. I will support it in UCI2WB too. Now we should only hope that all engines implemeting a certain variant will use the same name for selecting it...

I think the key to that is making sure these things are documented somewhere.
Perhaps a Wiki would be best, because then whoever is first to implement a variant can add it on there directly, rather than one person having to keep track of things...

UCI2WB now produces this for Sjaak II:

Code: Select all

hgm@hgm-xboard:~/uci2wb$ ./uci2wb sjaakii
xboard
protover 2
feature variants="normal,xiangqi" setboard=1 usermove=1 debug=1 ping=1 reuse=0 exclude=1 pause=1 sigint=0 sigterm=0 done=0
feature option="UCI2WB debug output -check 0"
feature myname="Sjaak II 1.0 RC3b (x86_64) (UCI2WB)"
feature oocastle=0
feature variants="chess,chess960,seirawan,shatar,makruk,shatranj,sittuyin,crazyhouse,chessgi,asean,ai-wok,spartan,pocketknight,kingofthehill,knightmate,amazon,chancellor,berolina,losalamos,micro,capablanca,gothic,embassy,courier,grand,opulent,omega,minishogi,shoshogi,shogi,torishogi,xiangqi,normal,fischerandom"
feature smp=1 memory=1 done=1

It seems I still would have to do some name conversion, e.g. chess -> normal. But before I do that I will try to get some consensus there. For currently Stockfish-variant callsit "standard". And uses "antichess" for some suicide / giveaway / losers variant.

[elcabesa]

it looks like it's not a cutechess problem, but a Vajolet problem

[Rochester]

So it would appear the CuteChessGUI 0.9.4 is "lightweight" also.

....

"Out" also seems to have a different meaning with you...

You 2 get a room!

[Ferdy]

Perhaps once the book is out of book (first time), do not allow the gui to use the book again, so that the use of book moves is guaranteed to be equal.

That is a book problem. Trying to solve it in the GUI would be a mistake. If you want to use a neutral 6-move book for starting tourney games, all lines in the book should be 6 moves. Otherwise white can do the last book move, tso that black has one less.

I created the polyglot book using Cute Chess from games with TC 3m+2s inc, around 1220 games only.

[Ferdy]

There was still a really nasty bug causing crashes in tournaments so I've made a bugfix release for 64-bit Windows and Linux: https://github.com/cutechess/cutechess/ ... /gui-0.9.4

There's also a bonus feature - support for the "UCI_Variant" UCI option.

When there is only 1 board, pressing game->close would quit Cute Chess.

[Laskos]

This is not entirely true. If engines run at 50%, 75% or 100% speed in one interface or another, it can affect the outcome in case the engines are scaling differently with time control. With ultra-fast games it is an often occurring issue. So, one better keeps the UI as separated as he can from the cores/threads used by engines, and often it's only doable by having a very sparsely CPU hungry UI.

They would have to scale extremely differently in order to get them outside each other's error bars, at this number of games. I mention 50% as an extreme case. 1% vs 10% would be more typical cases (i.e. the GUI using 1 vs 15 ms/move). There is no way you would see the scaling difference by just giving them 10% less time.

And there is no indication at all that the engines used did indeed scale differently.

Well, welcome to the world of hyper-fast testing. It is not advised for, but I tested at 1s+0.01s, modifying overhead to have some meaningful games, with contradicting results in Cutechess-GUI and Cutechess-CLI:

8 logical cores, 7 threads used by engines.

Code: Select all

Cutechess GUI:  16-20% CPU usage
Score of stockfish_16091415 vs komodo_101: 1204 - 1553 - 1243 [0.456]
ELO difference: -30.39 +/- 8.95
4000 of 4000 games finished.

Cutechess CLI:  4-6% CPU usage
Score of stockfish_16091415 vs komodo_101: 1391 - 1523 - 1086  [0.483] 4000
ELO difference: -11.47 +/- 9.18
Finished match

The lesson to learn: don't compare results in GUI and CLI below 3+0.03. In fact I will probably not switch right now to GUI, and use CLI. I cannot even see in GUI whether there are losses on time. It would be nice for it to count number or regularly finished games, time losses, illegal move losses, adjudications, mates and draw reasons.

[hgm]

Well, 10+0.01 is not really hyper fast. I was already doing 12-sec games with Joker80 (because of time odds) in 2008, without any problems, on a much slower computer than we can use today. But your conclusion in any case is that Cutechess GUI is appreciably 'heavier' (about a factor 3-4) as Cutechess-cli.

What exactly do the CPU percentages mean? Is that percentage from a single thread? If that remains below 100%, how could it affect the games if you reserved one thread for the GUI?