Winboard and Bismark - a unhappy couple (UCI hash options limitations)

[Guenther]

I receive requests from time to time about how to make certain engines run in Winboard or even generally.
Of course sometimes I don't remember immediately all pecularities of all programs and need to do some retesting.

With Bismark and WB I had a tough nut to crack though yesterday. Bismark would always crash in WB with 'usual' setups.
As I found no mentioning of this special case yet with the talkchess search, I thought I post here now for future reference.

Soon I found out by debugging that Bismark (=UCI) instead of MB for hash values uses a slot number, which defaults
to 22 = ~100MB already, with a max value of 64, which would then be already 100MB*2^42, which is much too much of course.

The problem is now that most users set a general hash size much higher in WB, may be 256 or 512 or similar and WB always
sends this plus the default hash size for EGTB. Bismark it seems will scale it down to 64 and still crash of course.

There is no possibility in WB, neither with polyglot nor with UCI2WB to send a single different hash to engines (anymore?) it seems.
Neither at all with (UCI2WB), nor w/o being overruled (Polyglot), all of this would Bismark make crash.
This means it would only work with a ugly workaround with Inbetween and changing the exact hash size sent to the desired number.
(or recompiling with some changes as the source is available, first trying a diff. max value and hoping it would scale each too high number
down again to the max)

I know this is mostly an incorrect usage of the hash option according to the uci specs, which mentions MB, but not everyone
understands that all examples in the specs often (or always?) are meant literally.

OTH what if uci engines would exist which just take a max of lets say 32MB and otherwise would stop working?
They would have the same problem w/o being 'incompatible' to the specs.
So I think even when there is a general hash option setting a different hash for programs should still be possible
and immediately be used at startup and not having sent the default size first.

With polyglot setting hash=23 (200MB)
WB setting: general hash=256/egt hash=16

Code: Select all

1611566214.418 POLYGLOT INI file "polyglot.ini"
1611566214.458 Adapter->Engine: uci
1611566214.668 Engine->Adapter: id name Bismark v. 1.4
1611566214.668 Engine->Adapter: id author Evgeny Shtranvasser
1611566214.668 Engine->Adapter: id name Bismark v. 1.4
1611566214.668 Engine->Adapter: id author Evgeny Shtranvasser
1611566214.668 Engine->Adapter: option name hash type spin default 22 min 0 max 64
...
1611566214.668 POLYGLOT [Engine] hash="23"
...
1611566214.668 Adapter->Engine: setoption name hash value 23
1611566214.668 POLYGLOT *** Mainloop started ***
1611566214.858 GUI->Adapter: xboard
1611566214.858 GUI->Adapter: protover 2
1611566214.858 Adapter->GUI: feature done=0
1611566214.858 Adapter->GUI: feature analyze=1
1611566214.858 Adapter->GUI: feature exclude=1
1611566214.858 Adapter->GUI: feature colors=0
1611566214.858 Adapter->GUI: feature draw=1
1611566214.858 Adapter->GUI: feature ics=1
1611566214.858 Adapter->GUI: feature myname="Bismark_14"
...
1611566214.958 GUI->Adapter: memory 272
1611566214.958 POLYGLOT setting the amount of memory to 272Mb
1611566214.958 POLYGLOT EGTB Cache is 0Mb
1611566214.958 Adapter->Engine: setoption name hash value 64
1611566214.958 GUI->Adapter: new
1611566214.958 Adapter->Engine: isready
1611566215.158 Engine->Adapter: info string bad hash size
1611566215.198 Engine->Adapter: EOF

With UCI2WB setting hash=23 and ucidebug on

Code: Select all

"Bismark_14" /fd=C:\Engines\UCI\Bismark_14 /fUCCI -firstOptions "Hash=23,UCI2WB debug output=1"

WB setting: general hash=256/egt hash=16

The extra option hash will be ignored and cannot be altered intentionally, only the GUI value will be considered.
This is ok in 99% of the cases, but too much babysitting IMHO, it should be possible to set a different hash.
May be there is a hidden way of doing this, I don't know yet?

Code: Select all

recognized 'normal' (-1) as variant normal
recognized 'normal' (-1) as variant normal
shuffleOpenings = 0
Version: WinBoard 4.9.1 + Bismark_14
Reset(1, 0) from gameMode 0
recognized 'normal' (-1) as variant normal
GameEnds(0, (null), 2)
shuffleOpenings = 0
StartChildProcess (dir="") UCI2WB Bismark_14 C:\Engines\UCI\Bismark_14
nice engine proc to 10
670 >first : xboard
protover 2
722 <first : feature setboard=1 usermove=1 debug=1 ping=1 name=1 reuse=0 exclude=1 pause=1 sigint=0 sigterm=0 done=0
722 >first : accepted setboard
722 >first : accepted usermove
722 >first : accepted debug
722 >first : accepted ping
722 >first : accepted name
722 >first : accepted reuse
722 >first : accepted exclude
722 >first : accepted pause
722 >first : accepted sigint
722 >first : accepted sigterm
722 >first : accepted done
722 <first : feature option="UCI2WB debug output -check 0"
722 >first : accepted option
722 >first : option UCI2WB debug output=1
722 <first : feature option="ponder always -check 0"
722 >first : accepted option
722 <first : # engine said: id name Bismark v. 1.4
732 <first : feature myname="Bismark v. 1.4 (UCI2WB)"
732 >first : accepted myname
732 <first : # engine said: id author Evgeny Shtranvasser
732 <first : # engine said: id name Bismark v. 1.4
732 <first : feature myname="Bismark v. 1.4 (UCI2WB)"
732 >first : accepted myname
732 <first : # engine said: id author Evgeny Shtranvasser
732 <first : # engine said: option name hash type spin default 22 min 0 max 64
732 <first : # engine said: uciok
732 <first : feature variants="normal,xiangqi"
732 >first : accepted variants
732 <first : feature smp=1 memory=1 done=1
732 >first : accepted smp
732 >first : accepted memory
732 >first : accepted done
752 >first : memory 272
752 >first : cores 1
752 >first : new
random
752 >first : level 40 2 0
752 >first : post
752 >first : hard
752 >first : easy
752 >first : ping 1
Impossible move , type = 0
752 <first : # queue 'memory', searching=0
752 <first : # command memory
752 <first : # queue 'cores', searching=0
752 <first : # command cores
752 <first : Error (unknown command): cores
752 <first : # queue 'new', searching=0
752 <first : # command new
752 <first : # setoption name hash value 272
752 <first : # isready
752 <first : # queue 'level', searching=0
752 <first : # queue 'ping', searching=0
752 <first : # engine said: readyok
752 <first : # ucinewgame
752 <first : # command level
752 <first : # command ping
752 <first : pong 1
5512 >first : force
StartChildProcess (dir="C:\Engines\WB\Abbess_20161211") Abbess_20161211
...
New game (0): Bismark v. 1.4 (UCI2WB)-Abbess 2016.12.11 (w)
6132 >first : computer
6132 >first : name Abbess 2016.12.11
6132 >second: computer
6132 >first : black
6132 >first : time 12000
6132 >first : otim 12000
6132 >first : white
book hit = (NULL)
6132 >first : go
nps: w=-1, b=-1
6142 <first : # queue 'name', searching=0
6142 <first : # command name
6142 <first : # queue 'black', searching=0
6142 <first : # queue 'white', searching=0
6142 <first : # queue 'go', searching=0
6142 <first : # command black
6142 <first : Error (unknown command): black
6142 <first : # command white
6142 <first : Error (unknown command): white
6142 <first : # command go
6142 <first : # start search
6142 <first : # position startpos moves
6142 <first : # go btime 120000 wtime 120000 movestogo 40
6152 <second: # new
...
Fatal Error: Error: first chess program (UCI2WB Bismark_14 C:\Engines\UCI\Bismark_14) exited unexpectedly
GameEnds(27, Error: first chess program (UCI2WB Bismark_14 C:\Engines\UCI\Bismark_14) exited unexpectedly, 2)

[hgm]

WinBoard has general work-around options -first/secondFeatures, which can be used to overrule the features that are actually sent by the engine, as these will be processed after reception of the feature done=1 command. This could be used to suppress sending of the common hash setting to the engine, by registering it in the engine list with the additional WinBoard option

-firstFeatures "memory=0"

This will not yet solve the sending of an alternatively encoded hash size. But you can do that by including a 'memory' command of your own design in the init string:

-firstInitString "memory 22\nnew\n"

I must admit that UCI2WB does not respect the engine's maximum for the Hash option; this is something I should definitely fix.

[Guenther]

WinBoard has general work-around options -first/secondFeatures, which can be used to overrule the features that are actually sent by the engine, as these will be processed after reception of the feature done=1 command. This could be used to suppress sending of the common hash setting to the engine, by registering it in the engine list with the additional WinBoard option

-firstFeatures "memory=0"

This will not yet solve the sending of an alternatively encoded hash size. But you can do that by including a 'memory' command of your own design in the init string:

-firstInitString "memory 22\nnew\n"

I must admit that UCI2WB does not respect the engine's maximum for the Hash option; this is something I should definitely fix.

Thanks for the info! Indeed this works. I did not think about it, as fucci can send options too (but w/o hash included obviously)
Do you know, if this would already work in old Winboard 4.62 using Polyglot?
The user with the request is still on that version and doesn't like to change it currently.

Code: Select all

recognized 'normal' (-1) as variant normal
recognized 'normal' (-1) as variant normal
shuffleOpenings = 0
Version: WinBoard 4.9.1 + Bismark_14
Reset(1, 0) from gameMode 0
recognized 'normal' (-1) as variant normal
GameEnds(0, (null), 2)
shuffleOpenings = 0
StartChildProcess (dir="") UCI2WB Bismark_14 C:\Engines\UCI\Bismark_14
nice engine proc to 10
704 >first : xboard
protover 2
727 <first : feature setboard=1 usermove=1 debug=1 ping=1 name=1 reuse=0 exclude=1 pause=1 sigint=0 sigterm=0 done=0
728 >first : accepted setboard
728 >first : accepted usermove
728 >first : accepted debug
729 >first : accepted ping
729 >first : accepted name
729 >first : accepted reuse
729 >first : accepted exclude
729 >first : accepted pause
730 >first : accepted sigint
730 >first : accepted sigterm
730 >first : accepted done
730 <first : feature option="UCI2WB debug output -check 0"
731 >first : accepted option
731 <first : feature option="ponder always -check 0"
731 >first : accepted option
732 <first : feature myname="Bismark v. 1.4 (UCI2WB)"
733 >first : accepted myname
733 <first : feature myname="Bismark v. 1.4 (UCI2WB)"
733 >first : accepted myname
734 <first : feature variants="normal,xiangqi"
734 >first : accepted variants
734 <first : feature smp=1 memory=1 done=1
734 >first : accepted smp
735 >first : accepted memory
735 >first : accepted done
755 >first : accepted memory
755 >first : accepted memory
755 >first : cores 1
755 >first : memory 22

[hgm]

I forgot when exactly I introduced the -firstFeatures option, but I still had an old 4.6.2 somewhere on my computer, and it did not crash when I specified this as 'Additional option'. And the InitString options have existed forever. So Carlos can be happy!

[Carlos777]

I forgot when exactly I introduced the -firstFeatures option, but I still had an old 4.6.2 somewhere on my computer, and it did not crash when I specified this as 'Additional option'. And the InitString options have existed forever. So Carlos can be happy!

I confirm that this works in the old WB 4.6.2. I'll give the new WB another chance, I promise.

Thanks HGM and Guenther!

[hgm]

Well, I can imagine that when you heavily invested in Polyglot settings file, the replacement of Polyglot by UCI2WB as the primary UCI adapter, what I did in the WinBoard-AA package, is not reallyw elcome. But this is not really a WinBoard property; it is just how I configured WinBoard in this package. In principle which adaptors WinBoard uses is determined by the setting of the /adapterCommand and /uxiAdapter options. (The latter for the UCCI/USI engines.) These settings specify the command WinBoard has to use instead of the engine command given by the -fcp option. To use Polyglot the option is configured as:

/adapterCommand='polyglot -noini -ec "%fcp" -ed "%fd" -uci NalimovCache=%defaultCacheSizeEGTB -uci GaviotaTbCache=%defaultCacheSizeEGTB'

The % signs in this indicate the name of a WinBoard option follows, and that the value of this option has to be substituted for it. This way the name of the engine executable (/fcp) and of the engine directory (/fd) are passed to Polyglot as its -ec and -ed arguments, while the WinBoard setting of the EGTB cache size is also communicated as value of the corresponding engine-defined UCI option.

Of course the polyglot.exe file has to be present in the WinBoard forder for this to work. When you run WinBoard once with the line above pasted into the 'Additional options' field of the Startup Dialog, it will from then on use Polyglot for engines that are accompanied by the /fUCI option.

The latest WinBoard has its own system for storing non-default settings of engine options, (namely in the engine list as /firstOptions option), so it is no longer dependent on the adapter storing these in an ini file dedicated to that engine. This to make it also possible to do that for engines that do not use an adapter at all. For this purpose a 'Make Persistent' button is always added to the Engine Settings dialogs. Operating that causes all the options that have non-default values to be added to the engine's line in the engine list as a /firstOptions value (replacing any previous /firstOptions option there).

Unfortunately there is no way to import settings from the pre-existing polyglot .ini files in the _PG folder.

[Ras]

I must admit that UCI2WB does not respect the engine's maximum for the Hash option; this is something I should definitely fix.

The minimum should also be considered. My engine doesn't allow switching off hash tables entirely and thus requires 1MB minimum. With memory 0 at the CECP end, that would be disregarded. However, it wouldn't crash my engine because it clips input values to their valid range.

[hgm]

But I am not sure what to do in that case. Setting the engine to the minimum it allows would not comply with the CECP command. I don't want to legitimize a way for the engine to cheat for its memory usage, by allowing it to specify a huge minimum, and then simply granting it. Perhaps I should have UCI2WB exit with a tellusererror message, but that is unlikely to make anyone happy. It seems mostly a hypothetical problem anyway (unlike exceeding the maximum).

One could argue that setting a large minimum is a UCI violation of the engine in the first place: the specs mention you should start with an insignificant amount of Hash, and it is obliged to report the current value in the 'option' command. So it would then have to report a 'default' that is smaller than the 'min', and it would not be a violation to leave it at its default.

Of course 1MB is OK; even engines that do not use TT at all typically get a 3MB memory image in Windows. I cannot imagine anyone would ever try to run XBoard with a common hash-size setting of 0, but if I had to prepare for that the most logical thing to do would be for WinBoard is disabling the sending of 'memory' commands in that case.

[Ras]

But I am not sure what to do in that case. Setting the engine to the minimum it allows would not comply with the CECP command.

I've looked up Shredder, Stockfish, and Demolito as other examples - all say 1MB minimum for the hashtables. So it's pretty common. Actually, even Crafty refuses to accept "memory 0" from CECP.

Means, the support for "memory 0" isn't there anyway - but the difference is that CECP engines must check the input size value because they don't announce that to the GUI beforehand. That's why Winboard can get away with "memory 0" for CECP, because engines will check and ignore it. Crafty doesn't clip btw., but ignores "memory 0" entirely. So it doesn't even try to get as close to the intended setting as possible.

For UCI engines, it's a protocol violation, and given the aversion against robustness code that I've seen here on Talkchess, I'm pretty sure it could crash some UCI engines. Others will clip (i.e. use 1 as setting), and others (e.g. Stockfish) will ignore an out of limits hashtable setting entirely, similarly to what Crafty does.

I don't want to legitimize a way for the engine to cheat for its memory usage

There's nothing you can do against deliberate cheaters on protocol level because an engine can always just ignore that option.

but if I had to prepare for that the most logical thing to do would be for WinBoard is disabling the sending of 'memory' commands in that case.

Given that "memory 0" doesn't tend to work anyway, that would be logical - but the UCI adaptor code should respect the announced minimum at least if it is not greater than 1, because it's common and not intended to cheat on performance. Also, it would work closer to what's intended, given that it's widespread to entirely ignore out of bounds values.

[hgm]

Another interpretation would be that specifying another minimum than 1 is a protocol violation of the engine. Like you say, if the engine wants to cheat there isn't much that you can do against it anyway, and rounding the requested value up to the minimum or ignoring the command altogether would merely be two different forms of cheating. I seem no technical reason why a minimum of 1MB for the Hash should make the usual hashing algorithms fail. UCI engines tend to cheat anyway by not counting Pawn hash, EGTB cache and such in the total.