Author: Eugene Nalimov
Date: 20:48:26 12/21/00
Go up one level in this thread
On December 21, 2000 at 21:53:57, Robert Hyatt wrote: >On December 21, 2000 at 13:33:35, Peter Kasinski wrote: > >>On December 21, 2000 at 10:18:26, Robert Hyatt wrote: >> >>>On December 21, 2000 at 09:45:23, Peter Kasinski wrote: >>> >>>>These are meant to be permanently stored in RAM, and thus the significant RAM >>>>requirement. At the same time Nimzo8 still uses Nalimov tablebases and assigns >>>>RAM for that. >>>> >>>>1. Isn't there an overhead of trying to use both? >>>>2. What is a reasonable strategy for allowing Nizmo8 to use one vs. the other? >>>>I.e. should a nominal amount of RAM be assigned for caching Nalimov tablebases >>>>and the rest (as much as possible) to Nimzo's own? >>>>3. Finally, does it make sense to increase these allocations at the expense of >>>>the main hash table size? >>>> >>>>If someone has info/interesting experiences with the above, please do share >>>>:)Thanks! >>>> >>>>PK >>>> >>>>ps. Merry Christmas to all (who celebrate)! >>> >>> >>>The Nimzo tablebases are win/lose/draw, which makes them much smaller than the >>>normal distance-to-mate tablebases. They are used only in the search as they >>>can't tell which move leads to the shortest mate. Once the root position is >>>5 pieces, normal tablebases have to be used to avoid repetitions, which is why >>>both are needed. >> >>Thanks, I was wondering about their size too. >>But what do you think Bob of the trade-off between using RAM for the main hash >>tables and tablebase caching? >> >>PK > > >I don't do that, so I can't really say. The issue is that the full set of 3-4-5 >piece files take 7.5 gigabytes. The win/lose/draw files should take 3/256 of >that amount, or roughly 88 megabytes. That is a lot of memory to dedicate to >the endings, but it might be worth it as there would be _no_ disk accesses >inside the search. I am afraid that 88 might be a bit low, as the win/lose/draw >tables might not compress as well as the full 8-bit tables. I would guess that >200 megabytes might be a reasonable guestimate... Sorry, Bob, you are wrong. You can pack ~5 W/D/L values in one byte (3**5==243, that is roughly equal to 256) instead of one full value, so your W/D/L tables would be ~5 times smaller than the full ones, not ~80 times smaller. Eugene >As far as EGTBs vs RAM, yes you get hurt in the middlegame, and make it up in >the endgame. You might even try demand=loading the files you need as you >encounter each endgame class for the first time, so that this isn't a >big problem...
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.