polyglot/xboard set hash memory conflict?

[Chan Rasjid]

Hello,

It seems xboard now has a new default hash memory option. Polyglot would send :-

1312393771.993 GUI->Adapter: accepted option
1312393771.993 GUI->Adapter: accepted done
1312393771.993 GUI->Adapter: memory 68
1312393771.993 POLYGLOT setting the amount of memory to 68Mb
1312393771.993 POLYGLOT Nalimov Cache is 0Mb
1312393771.993 Adapter->Engine: setoption name Hash value 68

But earlier my engine received:-

1312393771.993 Adapter->Engine: setoption name Hash value 256

which is under the UCI option section of the polyglot .ini file.

So my engine finally only set hash memory only to the default from xboard. I think other engines should be affected if they run under polyglot.

Rasjid.

[hgm]

Indeed, when running engines under XBoard, they get the amount of memory you specified in XBoard (in the Common Engine Settings dialog). Is there any GUI where you get different memory than what you ask for?

[Chan Rasjid]

Indeed, when running engines under XBoard, they get the amount of memory you specified in XBoard (in the Common Engine Settings dialog). Is there any GUI where you get different memory than what you ask for?

Now I found xboard has a common setoptions for engines!

It is now a polyglot/UCI engine problem. Only a UCI engine that uses "Hash" as the option name for setting hash memory would respond and set hash memory correctly. In running engine-engine matches with polyglot, it cannot be assumed that the engines are using the hash memory as set in xboard.

Rasjid.

[Chan Rasjid]

Indeed, when running engines under XBoard, they get the amount of memory you specified in XBoard (in the Common Engine Settings dialog). Is there any GUI where you get different memory than what you ask for?

Now I found xboard has a common setoptions for engines!

It is now a polyglot/UCI engine problem. Only a UCI engine that uses "Hash" as the option name for setting hash memory would respond and set hash memory correctly. In running engine-engine matches with polyglot, it cannot be assumed that the engines are using the hash memory as set in xboard.

Rasjid.

The UCI protocol has this :

* = Hash, type is spin
the value in MB for memory for hash tables can be changed,
this should be answered with the first "setoptions" command at program boot
if the engine has sent the appropriate "option name Hash" command,
which should be supported by all engines!

It should be interpreted that the UCI protocol reserve the option name "Hash" only for setting the main
transposition memory .

Rasjid.

[hgm]

The way it works in Polyglot is that it subtracts the EGTB cache size from the amount of memory XBoard says it can use, and sends that as hash.

This is in fact non-compliant with the defnition of the Hash option in UCI protool, which specifies Hash indicates the total size of all hash tables (plural), i.e. not just main hash, but also Pawn hash, EGTB cache etc. But asmost UCI engines are non-compliant in this respect (in fact I do not know a single one supporting EGTB that is), this seemed the best solution.

[Chan Rasjid]

The way it works in Polyglot is that it subtracts the EGTB cache size from the amount of memory XBoard says it can use, and sends that as hash.

This is in fact non-compliant with the defnition of the Hash option in UCI protool, which specifies Hash indicates the total size of all hash tables (plural), i.e. not just main hash, but also Pawn hash, EGTB cache etc. But asmost UCI engines are non-compliant in this respect (in fact I do not know a single one supporting EGTB that is), this seemed the best solution.

Most engine authors would take option Hash to be only for the main TT memory. We could have separate options like PawnHash, EvaluateHash, etc...and a UCI compliant GUI would just include those selections.

Rasjid.

[Desperado]

...indicates the totalsize of all hash tables (plural), i.e. not just main hash, but also Pawn hash, EGTB cache etc...

Hello HGM,

i dont agree here with you (yet ). I believe that _hash tables_ is
just a uncouth formulation for transposition table(s).

E.G. the Nalimov cache is also _extra_ cache, that is why egtb should
also get additional memory. If i now follow my own logic, splitting
tablebase cache from "hashtable" cache, i can use _extra_ memory
for everything else, like pawnHash or whatever.

Plural or not doesnt matter because there do exist many designs that
use multiple transTables
(replacement strategy or other reasons..)

Michael

[hgm]

Most engine authors would take option Hash to be only for the main TT memory. We could have separate options like PawnHash, EvaluateHash, etc...and a UCI compliant GUI would just include those selections.

Indeed, and since that is in direct violation of even the extremely loose specs of the UCI protocol, it means that most engines are non-compliant with the specs. It also means that most UCI engines cheat, by exceeding the amount of memory they are allowed to use accordingto the specs.

Polyglot does make an attempt to pre-empt this cheating w.r.t. the EGTB cache, because this cache is specified by a UCI standard option. Unfortunately, there is no standard option to specify size of Pawn hash, eval cache, material table, bitbase buffers and what have you. They could not be called anything, which makes it impossible for Polyglot to recognize them. Engines could even have the feature without any option to set it. Like a fixed size 2GB buffer for bitbases, and Polyglot would never know.