Houdart: The use of EGTB is part of the strength of an engine, so it's probably fair that EGTB are used for the test.
How did you estimate the +10 to +20 Elo strength improvement from EGTB?
VR has always said it is much less (like 2 ELO), and he got that from fixed depth testing (I think this methodology is bad, however, as EGTBs can reshape the tree a lot, and introduce new prunings). However, Nalimov and bitbases are two different things, even if Nalimov is on a fast solid-state drive. At some point, I tracked down the CCRL data for bitbase usage with Shredder and Toga/Scorpio (though I think Shredder's version is superior --- in fact calling these both "bitbases" is a bad idea to me, as the access is completely different --- Shredder uses what I presume is a run-length encoding and never "decompresses" anything into memory
per se, while Scorpio essentially imitates the Nalimov method and so needs to have blocks of memory set aside for that, and do Huffman decoding over 8K blocks, rather than run-length decoding over short segments). The numbers ranged from 10-25 ELO. I think there was a claim that the RobboBases added about 10 ELO in fast self-play games (I actually think self-play could
underestimate the difference here, as the game is more likely to be drawn before the endgame is reached). Of course, for any given engine it depends on how good/bad its non-EGTB endgame play is.
Gemuh:
- they need far more RAM than Gaviota EGTB.
- only few people can configure Robbobases correctly
- Robbobases are a bit buggy (see only draw in some winning endgames)
- Gaviota EGTB have bitbases also
- Gaviota EGTB are used by increasingly more engines.
I must be one of the few people in #2, I guess, though admittedly I use Linux rather than Windows, and I agree that the help for this could be superior.
I think your first point is a misnomer, as the whole point of RobboTripleBases seems to be that they are meant to be "instant access" because they fit in memory (like ShredderBases), and don't have to be loaded from the disk. You can change the RobboBase code to use the "TotalBases" from disk instead (I don't know how easy this is to do -- maybe just change TRIPLE_VALUE in
evaluation.c to RobboTotalBaseScore), and I suspect it will become somewhat slothful, just like disk access with Nalimov. As a reverse aspect to the larger RAM for the TripleBases, you can note that the TotalBases take less disk space (by a significant margin) than Gaviota or Nalimov (even less than FEG, largely because Robbo uses one-sided DTC).
When Ballicora first released his TBs, I did a few timings, and the RobboTripleBases were much faster, largely because of the disk access issue I think. The above nuance between types of bitbases puts Gaviota into the Nalimov/Scorpio class (I think), while to me the checkers/Shredder class is the superior one. Perhaps the best solution would be to allow the user to pre-load desired bitbases into RAM and have others load on-demand from the disk (loading bitbases would be more efficient than loading TotalBases from the standpoint of I/O throughput, though either is possible). As for your last point, I see no reason why you can't support more than one option.
Is there any way to download only 3-men Robbobases and have only 16 MB memory allocated for them ?
I must be missing something --- surely the 3-men TripleBases will fit into about about 25K? The 4-men fit into about 4MB.
