WinBoard protocol: memory command

[H.G.Muller]

I have just added a 'memory' command to WB protocol, which can be used to interactively set the memory use (hash tables, EGTB cache) of an engine. Here is its official definition:

1) Only protocol-2 engines that sent

feature memory=1

at startup amongst the other features will receive the memory command.

2) WinBoard will send to such engines for each new game, directly after the ponder commands ('hard' and/or 'easy'), the line

memory M

where M is a decimal number >= 1, which should be interpreted as a number of MegaBytes (binary, i.e. 1MB = 1024*1024 bytes). The engine should, in reaction to this command, resize its tables (main hash, EGTB cache, etc.) in such a way that the total memory usage is below the mentioned size.

It can decide itself how best to distributed the allotted memory amongst its various tables.

The way I implemented in WinBoard (4.3.15h and higher) is that I add the default Hash and EGTB-cache sizes (as set by the command-line options /defaultHashSize and /defaultCacheSizeEGTB, or from the "Options -> UCI..." menu, add 1MB to that for other tables (and to assure a minimum of 1 if both sizes were set to zero), and send that size to the engine in every initialization sequence (starting with 'new').

Perhaps the 1MB will in the future become an adjustable parameter, or other explicitly table sizes explicitly known to the GUI (e.g. Pawn hash) might be added to the total as well.

[Matthias Gemuh]

1) Only protocol-2 engines that sent

feature memory=1

at startup amongst the other features will receive the memory command.

2) WinBoard will send to such engines for each new game, directly after the ponder commands ('hard' and/or 'easy'), the line

memory M

I have implemented it in ChessGUI also.
Now you must document egtb path as a consequence.
Then egine authors will join us.

Matthias.

[Pedro Castro]

UCI engines that run on polyglot in Winboard_F will understand this feature memory?

I think I understand the idea, this fact has some advantages:

1. The configuration of the engines is simpler, saves time configuration, especially for tournament organizers who have to set up dozens of engines.

2. The system can be more just, all engines use the same memory, as a programmer could hide the size of a memory hash, I do not think we know where it is used each Mb of the program.

On the other hand there is one thing that worries me, you may have more memory instead favors a class from another class, for example access to bitbases 5 men of Scorpio can be about 45 Mb (using 32 for the cache), is possible that if an operator puts 128 MB limit, then perhaps it is better to use it primarily as a hash table that have bitbases. Vanish the bitbases or tables Namilov in tournament since virtually they no give ELO?

This may involve a small revolution that not all engines will follow. What will the organizers of tournaments with engines that do not follow?

[Ron Murawski]

UCI engines that run on polyglot in Winboard_F will understand this feature memory?

I think I understand the idea, this fact has some advantages:

1. The configuration of the engines is simpler, saves time configuration, especially for tournament organizers who have to set up dozens of engines.

2. The system can be more just, all engines use the same memory, as a programmer could hide the size of a memory hash, I do not think we know where it is used each Mb of the program.

On the other hand there is one thing that worries me, you may have more memory instead favors a class from another class, for example access to bitbases 5 men of Scorpio can be about 45 Mb (using 32 for the cache), is possible that if an operator puts 128 MB limit, then perhaps it is better to use it primarily as a hash table that have bitbases. Vanish the bitbases or tables Namilov in tournament since virtually they no give ELO?

This may involve a small revolution that not all engines will follow. What will the organizers of tournaments with engines that do not follow?

I agree with Pedro. I prefer EGTB cache size separate from main hash/ pawn hash/ eval hash/ etc. If a tournament has 3 and 4-men tables available only, then a small EGTB cache is enough and a large one is wasteful. If all EGTBs are available, then a larger egtb cache makes more sense. As an engine author I prefer not to worry about *which* egtb files are available to make a decision about how much memory should be allocated for egtb cache. Egtb cache size is a decision the tournament director should make, not the engine author.

The memory used for the opening book should also be excluded. Some engines keep their entire book in memory while others access the opening moves from disk. Should an engine that keeps the opening book in memory (like mine) be penalized? Would I need to totally release the memory for the opening book before allocating space for egtbs? For myself the programming needed for my engine would be needlessly complicated and very uninteresting.

Ron

[Matthias Gemuh]

I agree with Pedro. I prefer EGTB cache size separate from main hash/ pawn hash/ eval hash/ etc.

I must say that that was my intuitive thought also.
If an engine uses both egtb and egbb, should it split up the received cache as it likes ?. Or should egtb cache and egbb cache be sent separately ? I think we agreed egtb path and egbb path are different.
What if an in-memory book is shamelessly large (e.g. > 16 MB) ?

Matthias.

[H.G.Muller]

I don't think tournament directors set limits on memory usage just to spite engine authors. They do it for very practical reasons, to make two or four programs coexist in memory together without affecting each other.

So to bounce back your question "why should your engine be penalized for that?", I woud say: "why should your opponent be penalized for that?" The memory must come from somewhere, and even the fact that you could prove your engine uses it unnecesserily and hardly benefits from it would not mean that your opponent wil not suffer greatly if the memory is taken away from him, or overloaded so that his hash table gets swapped out because something you do during ponder.

As to the size of the EGTB cache: this could be a valid concern, although it smells of bad design: good EGTB code would make flexible use of available memory, independent of how many tablebases are available. People that want to use poor code that doesn't, should base its settings on the worst case. If that hurts them when there are only few EGTBs available, that provides a nice incentive to improve their code.

Nevertheless, when I will put in the EGTB support, I could still allow the engines to request an (indicative) setting of the EGTB cache size, which would allow a TD to give the engine a hint of how many EGTBs are available. Engines that trust the operator could then follow that recommendation. I have not defined that command yet, as it will be part of a larger package, which will be enabled by a single feature. It is likely to become something like feature EGT="nalimov", which will induce the GUI to send commands like EGTcache nalimov 32 and EGTpath nalimov F:/nalimov, if the user has supplied these settings. Thi has not been fully thought through yet, and I will probably wait releasing an official description until I actually have implemented them, as you never know which unforeseen problems I might encounter during implementation, which would be best solved by changing the protocol.

If the memory needed for bitbase probing would always be better spent on enlarging the hash table, I don't see any reason to keep bitbase probing alive. We also don't give engines extra time to calculate pi during a game, and engines that do will hurt themselves, no matter how interesting the numerology of pi might be. So why would we give them extra space to do things that do not improve their playing strength? There are zillios of techniques in Chess programming that are not competitive, but would still add some strength if you could do them on top of everything else. If considering all Pawn pushes in QS does not work, we could still allow all programs to redo their last iteration with such an extended QS, stopping their clocks during it, to keep the idea alive. But we don't do that... If bitbases are not competative, they should die. That is Darwnian evolution!

I don't see any problems with engines that do or don't follow. Like with any programming technique, engines that have chosen the suboptmal design will suffer in strength. Engines that need separate settings in a .ini file for EGBB cache and hash size might see them set by a TD to 32MB and 128MB, respectively, because the PC on which the tourney runs cannot afford more than 160MB per program without disk swapping. If engines that use the EGBB cache for extra hash would derive extra Elo from that, they would be stupid not to do it. The TD would not likely be able to detect for what purpose an engine uses it memory footprint, if the program is not open source. So I don't see how specifying the total for WB engines would change anything in this respect. It just reflects reality better. Setting hash size is basically a legacy from the time where the hash table reflected the entire memory use of the engine, as it was the only space consuming data-structure.

As to UCI engines running under Polyglot: they already get the hash size and EGTB cache size sent from WinBoard through the polyglot.ini made for them by WinBoard. So there is no need for Polyglot to understand the memory command, and indeed it doesn't.

[Ron Murawski]

As to the size of the EGTB cache: this could be a valid concern, although it smells of bad design: good EGTB code would make flexible use of available memory, independent of how many tablebases are available. People that want to use poor code that doesn't, should base its settings on the worst case. If that hurts them when there are only few EGTBs available, that provides a nice incentive to improve their code.

The Nalimov code is the same for all who use it. The smaller you make the egtb cache, the more the hard drive is forced to work. The smallest egtb caches access the hard drive the most often -- over time the hard drive wears out. For an engine author or a tournament director it is always best if engines use larger caches and minimize disk access. That is the best reason I can give you for not including egtb cache memory.

If I need to calculate the 'optimal size' for an egtb cache you are forcing me to read the entire directory of all tablebases from the egtb directory so I can make an intelligent decision. All other engine authors would be forced to do the same. All this extra disk access will reduce hard drive life expectancy.

In my own tournaments I avoid playing engines that access the hard drive incessantly when using their opening book. In-memory books are much kinder to my computer hardware, so I see this as a better design.

I also avoid engines that insist on writing log files after every game.

I believe most tournament directors want full control so they can choose options that minimize hard disk usage. Your present Winboard memory option tends to do the opposite.

Ron

[H.G.Muller]

I don't follow that line of reasoning at all. From what I understand from it, quite the opposite seems true to me: Allowing engines to use more physical memory than there is will enormously drive up the usage of hard disk, as even engines that are designed to run purely from memory will trigger swapping by the OS.

It seems also to me that engines that want to heavily probe EGTBs in some game stage would have made a very poor design choice by taking small EGTB cache for the benifit of larger hash: their search will be slowed down enormously by having to wait for the probes that could have been stisfied instantly had the relevant EGTB vlocks still be cached.

Nothing has to stop engine authors from having the TD set the EGTB cache size by other means (ini file, command-line option), and adding a memory command to WB protocol does not change any of this. Commands to facilitate setting of EGTB parameters will be added to WB protocol later anyway.

If there is a need for engines to know in advance how many tablebases there are, to avoid having each engine figuring it out for themselves, it seems to me that quoting an EGTB cache size is a very roundabout way to specify it. It i tied to one particular implementation which might soon be obsolete, so that in the future 40MB EGTB cache might mean that in order to run efficintly you need 20MB, or 60MB, or whatever. If it is important for engines to know the number of tablebases, it would be logical for the GUI to simply tell them the number of tablebases. In response to feature egt="nalimov", the engine could receive a command egts nalimov 120, telling it that there are 120 tablebases.
Or, if that is desirable, specify by number of men:

egts nalimov 3:5 4:40 5:160 6:0

Btw, it doesn't seem so strange to me that every engine would have to go through the entire EGTB directory to see which files there are (and thus automatically know how many there are). In the end they will have to probe the EGTBs, and how would you otherwise know which EGTBs there are to probe, and on which you better not spend time waiting?

[Matthias Gemuh]

I am comfortable with the memory command as proposed.
An engine author should split up memory as he likes.

If he steals extra memory for storing an opening book, ChessGUI has an option to compensate for that by telling engine to allocate less memory.

What if an engine uses 5-men bitbases but should allocate only 8 MB total ?
Would the engine crash ?

BTW, nobody needs to scan egtb folder to know amount of cache needed.
Number of men is queried once with one command and that's enough.

Matthias.

[H.G.Muller]

That is upto the engine programmer. Some programmers make their engine exit if, for instance, it cannot locate its opening book. Other programmer simply let it play without book in the same situation. I guess bitbases are the similar. If you see that memory is so cramped that you have no room for bitbases, you should refrain from using them. If you would cheat, and try to use the memory anyway, if the limit as realistic (e.g. if you were running on my 1999 Pentium-I laptop with only 16MB RAM), and you would use 32MB of memory-loaded bitbases, you might not crash. But the system would be swapping memory to disk like mad, and you would probably never search deeper than 1 or 2 ply.

Of course if the limit was set for no other reason than to handicap the engine, you might benifit from cheating, and grabbing 256MB when you are only allowed 8MB. No one is going to stop you (ecept an attentive TD, using the task manager to check your memory footprint). Compliance with WB commands (e.g. set depth) is always a voluntary action of the engine.

[Zach Wegner]

Personally I like the "memory" command. I think adding in protocol commands for different types of memory management are ugly ugly ugly. IMO this is a deficiency in UCI, it acts as if there are only two different types of memory that an engine can use and the engine can't decide for itself how best to allocate memory. It also gives an IMO unfair advantage to engines that use TBs, as H.G. points out (it could easily cheat). There's no reason to continue that policy in X/Winboard. For this reason I'd say to use a separate memory configuration option within winboard (i.e. not using a sum of options in the UCI dialogue), and let TDs figure out the UCI stuff.

Also, I'd say this memory command should only refer to "discretionary" memory, so that programs don't have to keep track of their working set and adjust accordingly. I suppose the book could be disregarded here (though some TDs might be pissed if your engine tries to load a 300mb book). I doubt any engine will use more than a MB or so anyways.

As far as the disk usage is concerned, well, that's life. You're not going to be able to test engines in a truly fair way on the same computer. Just one more reason for people to not use TBs.

[H.G.Muller]

Having a way to set the parameter passed in the 'memory' command independent from the UCI settings is a design choice of the GUI author. For the time being I took this solution in WinBoard because the input fields and options were already there in the menu, and I try to minimize investing in making new menu items before we have unified the xboard and WinBoard menus.

And I needed a quick fix to the hash-size problems, as I am distributing the Super-Chess package amongst a group of users expected to have a wide variety of (sometimes very) obsolete computer hardware, and a high degree of computer illiteracy, not the usual crowd of computer-chess enthousiasts. So I was looking for a quick solution to adjust the engine hash size through a menu command; command-line options I considered already too cumbersome. (People would have had to alter the 'target:' line in the shortcut to adjust the hash ize then.)

Adding the two UCI parameters plus 1MB did seem to provide a pretty even field between WB and UCI engines. I am not sure how much the memory footprint of the average UCI engine would exceed hash + EGTB cache. If using bitbases routinely makes them grab another 45MB, WB engines should be allowed that space too, in order not to be disadvantaged. (Perhaps add 50MB in stead of 1MB. I did not want to do that by default, as it would not have been poible to limit the memory usage of Fairy-Max to below 50MB, while for some members of our target population it was essential that it should be limited to 7MB.)

Rather than making the rules fuzzy by defining memory use that does and that does not have to be counted, I prefer the limit given to the engine to be a hard one, and the operator to decide how much extra to allow (on top of UCI hash + egtb cache). Of course the operator might than as well decide on the total, rather than on the extra. If he know all engines use a bitbase set which requires 45MB, he can give 128MB hash and 32MB EGTB cache to UCI engines, and 210MB (=128 + 32 + 45 bitbase + 5 scratch) memory limit to the WB engines.

[Ron Murawski]

I don't follow that line of reasoning at all. From what I understand from it, quite the opposite seems true to me: Allowing engines to use more physical memory than there is will enormously drive up the usage of hard disk, as even engines that are designed to run purely from memory will trigger swapping by the OS.

What I said is: the more disk reading/writing, the faster a drive will wear out. I also said that larger caches cause less disk activity,

I did not mention that overly-large caches will also cause increased activity. This is a valid point.

It seems also to me that engines that want to heavily probe EGTBs in some game stage would have made a very poor design choice by taking small EGTB cache for the benifit of larger hash: their search will be slowed down enormously by having to wait for the probes that could have been stisfied instantly had the relevant EGTB vlocks still be cached.

Exactly. Small caches cause much more disk activity. My only point was that a cache that will access 3 men egtbs only can be made smaller than one that will access 3, 4, and 5-men tables.

Nothing has to stop engine authors from having the TD set the EGTB cache size by other means (ini file, command-line option), and adding a memory command to WB protocol does not change any of this. Commands to facilitate setting of EGTB parameters will be added to WB protocol later anyway.

If there is a need for engines to know in advance how many tablebases there are, to avoid having each engine figuring it out for themselves, it seems to me that quoting an EGTB cache size is a very roundabout way to specify it. It i tied to one particular implementation which might soon be obsolete, so that in the future 40MB EGTB cache might mean that in order to run efficintly you need 20MB, or 60MB, or whatever. If it is important for engines to know the number of tablebases, it would be logical for the GUI to simply tell them the number of tablebases. In response to feature egt="nalimov", the engine could receive a command egts nalimov 120, telling it that there are 120 tablebases.
Or, if that is desirable, specify by number of men:

egts nalimov 3:5 4:40 5:160 6:0

I like that solution!

Ron

[H.G.Muller]

What I said is: the more disk reading/writing, the faster a drive will wear out.

Even that is not obvious to me: the disk is spinning always, and the head is always in contact with the media. I don't think hard disks have a head load/unload like floppies had; that would take way too much time to engage them. I am also not sure if they park the head somewhere when there is no activity (laptop drives might). So the only difference would be the seeks, and modern disks no longer use stepper motors, but just balance the head assembly between two magnetic coils. It is hard to believe that moving the heads this way would cause significant wear on the bearings of the head assembly, if the disk itself is spinning all the time at a multiple of that speed.

I like that solution!

Which would you like better? The simple number, or the breakdown by number of men? In future formats, that might treat P-slices as separate tablebases, it is not so obvious how you should qualify them. My inclination is to use the single number, and let the TD set it as a WinBoard parameter Then WinBoard would not have to know at all what it means, and it could actually mean different things for different formats. E.g. for "nalimov" it could mean number of files, for "scorpio" it could mean nr of MegaBytes.

[Ron Murawski]

I like that solution!

Which would you like better? The simple number, or the breakdown by number of men? In future formats, that might treat P-slices as separate tablebases, it is not so obvious how you should qualify them. My inclination is to use the single number, and let the TD set it as a WinBoard parameter Then WinBoard would not have to know at all what it means, and it could actually mean different things for different formats. E.g. for "nalimov" it could mean number of files, for "scorpio" it could mean nr of MegaBytes.

I prefer this one:
egts nalimov 3:5 4:40 5:160 6:0

What I said is: the more disk reading/writing, the faster a drive will wear out.

Even that is not obvious to me: the disk is spinning always, and the head is always in contact with the media. I don't think hard disks have a head load/unload like floppies had; that would take way too much time to engage them. I am also not sure if they park the head somewhere when there is no activity (laptop drives might). So the only difference would be the seeks, and modern disks no longer use stepper motors, but just balance the head assembly between two magnetic coils. It is hard to believe that moving the heads this way would cause significant wear on the bearings of the head assembly, if the disk itself is spinning all the time at a multiple of that speed.

I have friends who remain in the computer repair business. Many of them have remarked that the diligent user who constantly defragments his hard drive is much more likely to have it fail than the casual user who never runs defrag.

My understanding of hard drives is that each data bit can be read-from / written-to only a finite number of times. With usage the surface degrades, magnetic bits become weaker, and the platter eventually wobbles: the position as well as the strength of the magnetic bits become less certain. The "SMART" technology to predict disk failures looks for this uncertainty. Here's the Wikipedia entry for SMART
http://en.wikipedia.org/wiki/Self-Monit ... Technology

Here's an article about magnetic wobble:
http://www.itpro.co.uk/120196/magnetic- ... sk-failure

You can quote sources and "prove" or "disprove" almost any statement about the cause of hard drive failures. It is my *belief* that heavy usage causes failures. I usually have at least 12 computers running. Some are on all the time, some get shut off every night, some get heavy usage, some get light usage. From my own experience it is the drives with the heaviest usage that usually fail the soonest for me.

Ron

[F. Bluemers]

Well,long ago ,heavy tb usage killed 2 hard-discs here (atleast that is what i believe).

For the next dirty-tour editions I will use a usb-stick with 3-5man bases.
Its cheap,no risk of breaking a hd and its even faster

Code: Select all

shredder 7.04,tabebases on hard-disc
8/8/6k1/R2pr3/P7/8/5P2/5K2 b - -


 13/25    0:10    -0.86    1...Kf6 2.Ta6+ Kf5 3.Ta8 Ke4 4.a5 Kd3 5.f3 d4 6.a6 (2.561.624) 238
 14/27    0:14    -0.90    1...Kf6 2.Ta6+ Kf5 3.Ta8 Ke4 4.Tg8 d4 5.Ke2 Kf5+ 6.Kd3 Ta5 7.Tf8+ Ke6 8.Kxd4 Txa4+ 9.Ke3 Ta3+ 10.Kf4 Ta4+ 11.Kg5 Ta5+ 12.Kg6 (3.866.100) 261
 14/29    0:17    -0.89++   1...Te4 2.f3 Te3 3.Tb5 Txf3+ 4.Ke2 Ta3 5.a5 (4.468.516) 256
 14/29    0:18    -0.89    1...Te4 2.f3 Te3 3.Kg2 Ta3 4.Kg3 Kf6 5.Kf4 d4 6.Ke4 Te3+ 7.Kxd4 Ke7 (4.630.807) 248
 15/31    0:32    -0.84    1...Te4 2.Ta8 d4 3.f3 Te3 4.Kf2 Ta3 5.Ke2 Kf5 6.a5 Ke5 7.Kd1 (8.694.336) 267

shredder 7.04 tb on usb stick
 13/26    0:04    -0.82    1...Te4 2.Ta6+ Kf5 3.Ta8 d4 4.f3 Te3 5.Tf8+ Kg6 6.Td8 Txf3+ 7.Ke2 Ta3 8.Ta8 (1.498.368) 352
 14/29    0:05    -0.82    1...Te4 2.Ta6+ Kf5 3.Ta8 d4 4.Tf8+ Kg6 5.f3 Te3 6.Td8 Txf3+ 7.Ke2 Ta3 8.Ta8 (2.244.672) 393
 15/31    0:14    -0.73    1...Te4 2.Kg2 Kf6 3.Ta8 Tb4 4.Kf3 Ke5 5.Td8 Txa4 6.Te8+ Kd6 7.Tf8 (7.435.737) 524
 16/32    0:21    -0.97    1...Te4 2.Kg2 Kf6 3.Ta8 d4 4.Kf3 Te7 5.Ta5 Ke6 6.Ke2 Tf7 7.Kd3 Kd7 (11.360.198) 540



Best Fonzy

[H.G.Muller]

Perhaps I should put the info about the number of tablebases in the same command as the tablebase path, because logically they belong together (describing the part of the file system where the tablebases are). Like

egtpath nalimov F:\endgames\nalimov 3:5 4:40

As different future tablebase formats might have other informton that is relevant to them, I am in favor of rather loose definition of this command within WB protocol, like

egtbpath FORMAT PATHNAME [OTHERINFO]

where the syntax of the optional OTHERINFO is not really part of WB protocol, but can be defined by the inventor of the tablebase format. For nalimov we could define it as a space-separated list of MEN:NRFILES pairs. WinBoard would simply pass on the string the user had specified for the pathname, onto which the OTHERINFO is piggybacked, and never needs to know which part of it is pathname, which part of it is OTHERINFO, or what it means. E.g. through a comamnd-line option

/egtFormats="nalimov F:\endgames\nalimov 3:5 4:40,scorpio F:\endgames\bitbases 45"

WinBoard would parse the string argument as comma-separated list, and take the part before the first space in each item of the list a format name, and remember everything after that space as the string to be sent for that format.

The format names would be matched against those in the comma-separated list the engine sends with the features:

feature egt="nalimov,scorpio"

For each match (in this example both for nalimov and scorpio) it would then reply by the corresponding egtpath command, where as first argument to the command it would echo the format name that matched, and as second argument the string the user specified for this. So in this case

egtpath nalimov F:\endgames\nalimov 3:5 4:40
egtpath scorpio F:\endgames\bitbases 45

Format names specified by the engine, but not matching anything specified by the user, would not lead to any response. The asumption of the engine should be that the EGTs are not available unless it gets an explicit egtbpath command for them. Similarly, formats specified by the user, but not amongst the engine features, will also not lead to any commands; the assumption will be that the engine does not support them.

[F. Bluemers]

Perhaps I should put the info about the number of tablebases in the same command as the tablebase path, because logically they belong together (describing the part of the file system where the tablebases are). Like

egtpath nalimov F:\endgames\nalimov 3:5 4:40

As different future tablebase formats might have other informton that is relevant to them, I am in favor of rather loose definition of this command within WB protocol, like

egtbpath FORMAT PATHNAME [OTHERINFO]

where the syntax of the optional OTHERINFO is not really part of WB protocol, but can be defined by the inventor of the tablebase format. For nalimov we could define it as a space-separated list of MEN:NRFILES pairs. WinBoard would simply pass on the string the user had specified for the pathname, onto which the OTHERINFO is piggybacked, and never needs to know which part of it is pathname, which part of it is OTHERINFO, or what it means. E.g. through a comamnd-line option

/egtFormats="nalimov F:\endgames\nalimov 3:5 4:40,scorpio F:\endgames\bitbases 45"

WinBoard would parse the string argument as comma-separated list, and take the part before the first space in each item of the list a format name, and remember everything after that space as the string to be sent for that format.

The format names would be matched against those in the comma-separated list the engine sends with the features:

feature egt="nalimov,scorpio"

For each match (in this example both for nalimov and scorpio) it would then reply by the corresponding egtpath command, where as first argument to the command it would echo the format name that matched, and as second argument the string the user specified for this. So in this case

egtpath nalimov F:\endgames\nalimov 3:5 4:40
egtpath scorpio F:\endgames\bitbases 45

Format names specified by the engine, but not matching anything specified by the user, would not lead to any response. The asumption of the engine should be that the EGTs are not available unless it gets an explicit egtbpath command for them. Similarly, formats specified by the user, but not amongst the engine features, will also not lead to any commands; the assumption will be that the engine does not support them.

while the memory command is one step forward ,this looks like two steps back
imo if an engine wants to use egtb's it should be smart enough to handle them itself and should do its own counting,if it wants to.
Just setting a path should do.


Best
Fonzy

[Zach Wegner]

I have to agree with Fonzy here. The whole idea of sending the number of tablebases available is so that engines can allocate a reasonable amount of cache. This is IMO a microoptimization that will make very little difference, and most engine authors probably won't make use of it. For those that care enough about the difference (at most a few Elo), I don't think it would be so hard to write a 10 line function to count the TBs.

[H.G.Muller]

... For those that care enough about the difference (at most a few Elo), I don't think it would be so hard to write a 10 line function to count the TBs.

In fact only one open-source engine would have to write that code, as they can all clone it from each other, right?