Author: Robert Hyatt
Date: 12:21:09 12/22/00
Go up one level in this thread
On December 21, 2000 at 23:48:26, Eugene Nalimov wrote: >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 > I wanted to say 5 times. But somehow I convinced myself that it was actually 3/256, since we normally store 256 unique states per entry, and only need 3 states for w/l/d. Your number means we would need about 1.5 gigs of memory to hold all the 3-4-5 piece w/d/l files. Not going to happen on my machines. :) Not worth it. The error I made was a simple one. Probably due to the late hour and advanced age. :) Thanks for watching carefully. Need to keep me straight when I wander. :) > >>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.