Alex Berger wrote:I could not specify the -defaultHashSize just for one engine; for example Rybka uses processes (opposed to threads)-so the Hash size would be multiplied by the cpu-cores (no problem whatsoever with dualcore; but on a quad with longer timecontrols this could lead to annoyences). Old polyglot did let me specify the Hash differently for each engine.
How could that be done now?
If it does, then it is a clear Rbka bug. UCI SMP engines are not supposed to multiply their hash size by the number of cores they use. There are many methods to pamper non-cmpliant engnes so they can be used; The InBetween adapter can be very useful for that. As a general principle, I try to avoid putting features in XBoard that only serve to correct / compensate errors that ly with the engine.
Second: I have no Idea how to use the egtb cache feature as intended. Again, I cant' specify it for each engine (so it seems) - but the memory get claimed in any case. Whether both engines are able to use egtb does not interest xboard (is this assumption wrong?).
In the version of XBoard you are using (4.4.2), the EGT cache size and polyglotBook info from the dialog is only passed to Polyglot if you invoke the engine with the option -fUCI or -sUCI. Never if you invoke Polyglot explicitly by writing something like
-fcp "polyglot fruit.ini". This is done because in that version (and older WB versions, upto Winboard_x), the -fUCI option lets XBoard prepare a polygot.ini temporary file, with the engine neme, directory, hash and cache size in it and pass that to Polyglot. As XBoard does not automatically send EGTB cache size to the engine (this is not a concept that WinBoard engines know, they just are told their memory limit and decide for themeselves how much of that to use for EGTB cache), Polyglot will smply use what is in the polyglot.ini file. (Either the synthetic one, or the one you provided). So it is easy to specify the EGTB cache per engine: just invoke Polyglot explicitly, with a poygot.ini file that specifies the cache size you want.
My case: letting some of the RobboLitos play with his own Tablebases. There is a cache option (up to 2048 mb) for that which the engines communicates. The 'cache' (from the polyglot.ini) value won't get accepted by xboard, but the directory will, so after changing it in commandline (setting -defaultCacheSizeEGTB 2048) xboard will claim an amount of 4096Mb memory because a match is played - besides as far as I can see, the cache won't get filled with useful stuff, it's just there.
Not completely sure what you are trying to explain here. XBoard never 'accepts' anything from the polyglot.ini file, it is completely unaware of it, unless it is a polyglot.ini file it made itself in response to the -fUCI / -sUCI option. The newer Polyglots, however, are aware of the meaning of the
memory command XBoard sends them, and how that differs from the UCI option 'Hash'. So they will use the EGTB cache size specified in the polyglot.ini to send to the engine, and subtract that from the total amount of memory that XBoard says they can use, and communicates the left-over as Hash to the engine. Because hystorically the WinBoard dialog that specified hash size and EGTB cache size only worked for UCI engines, the total allowed memory usage is calculated by XBoard through adding those. So if you want both engines to run with 2GB, it really does not matter if you set -defautHashSize to 2048 and -defaultCacheSizeEGTB to 0, or set them both to 1024. (Unless you use the -fUCI option, which transmits them separatey to Polyglot through the synthetic polyglot.ini file. But if you don't want that, simply do not use the option.)
So after giving each engine 2048MB of memory, you can divide that up on a per-engine basis into cache and hash, by specifying the EGTB cache size in the polyglot.ini. So you could set it for Robolito to 2048, so it would run with 2048MB cache and 0MB hash, and for a UCI opponent to 4MB, so it will run with 4MB cache and 2044MB hash.
I am not sure what to make of your last remark. If an engine does not use the memory allocation it is granted, or fills it with useless data... That sounds pretty much like an engine bug to me. Not much XBoard or Polyglot could do against that.
Could you help me here H.G.M? How about a switch, to let xboard, when asked specifically, accept all of polyglot's option to play with? Would that be very ugly?
If you want Polyglot to ignore the memory and cores commands that XBoard sends it, why don't you simply use an old Polyglot version that does not support these options? It makes little sense to equip Polygot with an option "behave as a defective Polyglot" or XBoard with an option "make a good Polyglot behave as if it was a defective one" if there are already so many defective Polyglots around...
