Stockfish+

[Eduard]

I use Engine TBs and GUI TBs. Never had any problems, on the contrary. Here is a problem with the engine.

[kranium]

That doesn't happen with draws. It happens on PlayChess, and whenever the engine sees itself clearly at an advantage in the endgame. So far, all other opponents have given up before they are mated.

I use 4 GB hash (with Ryzen 3900X), that's as much as with all other engines. The last time I played with Kayra 1560 games in a row, and that is my first loss since Dec. 14, 2021.

Were you using the option GUI tablebases or engine tablebases? I found that using GUI tablebases on playchess when getting low on time I would either get a draw in a winning position or a time loss due to engine not moving but that was with any engine, about two years ago.

Thx for letting us know that.

I'm running games now, simultaneously on 2 machines
8 threads 1024 hash
1min + 1 sec / TBs / no adjudication
most games are terminated by insufficient material, 50-move rule, or mate

I'll let it run overnight (or longer), or longer to see if I can replicate what happened in Eduard's endgame.

[kranium]

That doesn't happen with draws. It happens on PlayChess, and whenever the engine sees itself clearly at an advantage in the endgame. So far, all other opponents have given up before they are mated.

I use 4 GB hash (with Ryzen 3900X), that's as much as with all other engines. The last time I played with Kayra 1560 games in a row, and that is my first loss since Dec. 14, 2021.

Thanks much for playing so many games with stockfish montecarlo.

Concerning 4 GB hash, I hope you don't mind a friendly suggestion:
I think 2 GB would definitely be a better choice for your system at this TC

Here's my thinking:
In your case, your AMD system (w/ 32 threads) gets 24,000 kN/s right?
(German format) 24.000 kN/s = 24,000 kN/s
24,000 x 1000 or 24,000,000 nps

5 minute game = 300 secs
if average moves per game = 60, then
average time per move = 5 sec

Stockfish tt entry is now = 10 bytes (used to be 16 I believe)
so
5 secs x 24,000,000 nps x 10 bytes = 1,200,000,000 bytes
1,200,000,000 bytes / 1024 = 1,171,875 kB
1,171,875 kB / 1024 = 1,144 MB
1,144 Mb / 1024 = 1.14 GB

1,144 MB is the hash size that should fill up after 5 secs of analysis on your machine
so, IMO 2048 MB is a good choice (about twice as much as you'd need for average move time)

take a close look at 'hash full' output during a game to see if you're at 25%, 50%, 75%, or whatever

The reason I'm mentioning all this is because you seem quite serious about and devoted to chess engine competition...
and I'm pretty sure that a hash size that's too large, especially way too large, may have a negative impact on performance.
(time-to-depth is critical)

someone tested it here:
https://groups.google.com/g/fishcooking/c/FWP3uSFlpEo

You can test this yourself and possibly optimize performance by measuring time-to-depth
go to command-prompt
'setoption name Hash value 1024'
'go depth xx' at varying hash sizes
record the times

or even easier, use bench:
bench [hash] [threads] [depth]
bench 1024 8 32 (for ex)

[Eduard]

Thank's for the Tipps. I take everything very seriously. So of course I tested different HT sizes, I play a lot. Yes, if it is moved after only 5s then 2 GB is better. However, the engine often calculates for 30s or even 60s. After that, the hash is full with 4 GB. Especially in critical positions it shows that I am correct with this, but I will still test with 2 GB.

I'm now running a test without MCTS (version 07.01.22) on PlayChess. I want to see if the error happens without MCTS. You should perhaps be playing with no bonus time, it happened in the game with no bonus time.

[kranium]

Thank's for the Tipps. I take everything very seriously. So of course I tested different HT sizes, I play a lot. Yes, if it is moved after only 5s then 2 GB is better. However, the engine often calculates for 30s or even 60s. After that, the hash is full with 4 GB. Especially in critical positions it shows that I am correct with this, but I will still test with 2 GB.

I'm now running a test without MCTS (version 07.01.22) on PlayChess. I want to see if the error happens without MCTS. You should perhaps be playing with no bonus time, it happened in the game with no bonus time.

PS I'm not suggesting hash size had anything to do with your lost game.

my opinion, no increment = no good, especially online with so much possible network lag and/or other issues
If you uncheck MCTS, you're running pure SF dev...

I'm running MCTS games...
8 threads 1024 hash
1 min + 1 sec / TBs / no adjudication

Intel i9
1: Stockfish+070122_x64_avx2 32.0/32 ································· 11111111111111111111111111111111 0.00
2: Fridolin_3.10 0.0/32 00000000000000000000000000000000 ································· 0.00

AMD Ryzen
1: Stockfish+070122_x64_avx2 30.0/30 ································· 111111111111111111111111111111 0.00
2: Fridolin_3.10 0.0/30 000000000000000000000000000000 ································· 0.00

all games have ended in mate so far, has been perfect, no issues

I'll let it run until tomorrow afternoon

[George Sobala]

I confess to being confused. Perhaps you could enlighten?

Only the second thread undertakes a montecarlo search (i.e. if idx==1, line 341 in search.cpp). So when run single-threaded, you just get a standard Stockfish search even if MCTS is set to true. When run multi-threaded, thread 1 (the second thread) does MCTS whilst the other threads do AB. You get this sort of output from the command line:

Code: Select all

george@Georges-iMac-Pro-2 src % ./stockfish 
Stockfish+ 080122 by the Stockfish developers (see AUTHORS file)

Compiled using   : clang++ 12.0.5 on Apple
Compile settings : 64bit AVX2 SSE41 SSSE3 SSE2 POPCNT
Build date/time  : 2022-Jan-08 04:09:34

uci
id name Stockfish+ 080122
id author the Stockfish developers (see AUTHORS file)

option name Debug Log File type string default 
option name Threads type spin default 1 min 1 max 512
option name Hash type spin default 16 min 1 max 33554432
option name Clear Hash type button
option name Ponder type check default false
option name MultiPV type spin default 1 min 1 max 500
option name Skill Level type spin default 20 min 0 max 20
option name Move Overhead type spin default 10 min 0 max 5000
option name Slow Mover type spin default 100 min 10 max 1000
option name nodestime type spin default 0 min 0 max 10000
option name UCI_Chess960 type check default false
option name UCI_AnalyseMode type check default false
option name UCI_LimitStrength type check default false
option name UCI_Elo type spin default 1350 min 1350 max 2850
option name UCI_ShowWDL type check default false
option name SyzygyPath type string default <empty>
option name SyzygyProbeDepth type spin default 1 min 1 max 100
option name Syzygy50MoveRule type check default true
option name SyzygyProbeLimit type spin default 7 min 0 max 7
option name Use NNUE type check default true
option name EvalFile type string default nn-ac07bd334b62.nnue
option name MCTS type check default false
option name Book1File type string default <empty>
option name Book2File type string default <empty>
option name BestBookMove type check default true
option name BookDepth type spin default 255 min 1 max 255
uciok
setoption name MCTS value true
setoption name Threads value 4
go movetime 60000
...
info depth 38 currmove b1a3 currmovenumber 17
info depth 38 currmove g1h3 currmovenumber 18
info depth 38 currmove b2b4 currmovenumber 19
info depth 38 currmove g2g4 currmovenumber 20
info depth 39 seldepth 43 multipv 1 score cp 37 nodes 471592830 nps 8832649 hashfull 1000 tbhits 0 time 53392 pv e2e4 e7e5 g1f3 b8c6 f1b5 g8f6 e1g1 f6e4 f1e1 e4d6 f3e5 c6e5 b5f1 f8e7 e1e5 e8g8 d2d4 d6e8 c2c4 e7f6 e5e1 d7d5 c4d5 d8d5 c1e3 d5a5 b1c3 c8e6 c3a4 a8d8 a2a3 a5d5 a4c3 d5b3 d4d5 e6d5 c3d5
info depth 40 currmove e2e4 currmovenumber 1
info depth 40 seldepth 26 multipv 1 score cp 48 lowerbound nodes 485346219 nps 8831059 hashfull 1000 tbhits 0 time 54959 pv e2e4
info depth 39 currmove e2e4 currmovenumber 1
info string move 20 g2g4 win% 11.7 visits 3676
info depth 40 seldepth 26 multipv 1 score cp 48 nodes 529744720 nps 8828931 hashfull 1000 tbhits 0 time 60001 pv e2e4
info string move 19 b2b4 win% 20.435 visits 8753
info string move 18 g1h3 win% 32.817 visits 24942
info string move 17 f2f3 win% 32.817 visits 24942
info string move 16 h2h4 win% 34.349 visits 28471
info string move 15 b1a3 win% 34.682 visits 29311
info string move 14 a2a4 win% 38.088 visits 39866
info string move 13 f2f4 win% 38.435 visits 41188
info string move 12 b2b3 win% 44.017 visits 73077
info string move 11 d2d3 win% 47.793 visits 117600
info string move 10 h2h3 win% 48.651 visits 133280
info string move 9 a2a3 win% 50.000 visits 165407
info string move 8 b1c3 win% 50.736 visits 188424
info string move 7 c2c3 win% 51.227 visits 206780
info string move 6 e2e3 win% 52.574 visits 275922
info string move 5 d2d4 win% 53.308 visits 331913
info string move 4 c2c4 win% 53.552 visits 355048
info string move 3 g2g3 win% 54.405 visits 463398
info string move 2 g1f3 win% 56.345 visits 1233358
info string move 1 e2e4 win% 57.668 visits 325033603
bestmove e2e4 ponder e7e5

Note the huge number of visits for e2e4 compared to all others.

I am also puzzled that although the UCI Option MCTS is set to type check (i.e. boolean true/false), elsewhere in the code its value is assigned to variable mctsType which is later tested against value "Multi".

I am posting this here rather than in the github as some people already seem to be testing the MCTS produced by this engine, and so the above observations are of general interest.

[Eduard]

It will be difficult to reconstruct my faulty PlayChess game. Stockfish+ 070122 won today several games, but unfortunately everything with TB Endgame where the GUI mated with 6 pieces.

Most games on PlayChess either end with a resign, or the engine has only so much material that it will be a TB win. Such advantages (against very weak engines) where opponent will be mated earlier are very rare.