Author: Robert Hyatt
Date: 12:23:38 03/30/01
Go up one level in this thread
On March 30, 2001 at 14:42:34, Christophe Theron wrote: >On March 30, 2001 at 13:00:35, Robert Hyatt wrote: > >>On March 30, 2001 at 12:28:20, Christophe Theron wrote: >> >>>On March 30, 2001 at 09:30:06, Vincent Diepeveen wrote: >>> >>>>On March 29, 2001 at 13:31:59, Christophe Theron wrote: >>>> >>>>>On March 29, 2001 at 09:14:57, Robert Hyatt wrote: >>>>> >>>>>>On March 29, 2001 at 06:22:13, Jouni Uski wrote: >>>>>> >>>>>>>On March 29, 2001 at 06:17:50, Alexander Kure wrote: >>>>>>> >>>>>>>>On March 29, 2001 at 04:37:19, Tony Werten wrote: >>>>>>>> >>>>>>>>>Hi all, >>>>>>>>> >>>>>>>>>until what depth do various programs probe the tablebases ? >>>>>>>>> >>>>>>>>>cheers, >>>>>>>>> >>>>>>>>>Tony >>>>>>>> >>>>>>>> >>>>>>>>Hi Tony, >>>>>>>> >>>>>>>>In London 2000, I let Nimzo 8 play with a depth of 6 plies, but later I came to >>>>>>>>the conclusion that 8 plies might be better overall. This is indeed the default >>>>>>>>setting of NimzoX and Varguz playing on ICC. >>>>>>>> >>>>>>>>Greetings >>>>>>>>Alex >>>>>>> >>>>>>>Sorry one stupid question: is this the first or last 6/8 plys? >>>>>>> >>>>>>>Jouni >>>>>> >>>>>> >>>>>>His statement would make no sense if it were the _last_ 6-8 plies. Those >>>>>>are the ones that kill performance if you aren't careful. The first 6-8 plies >>>>>>don't cost a thing. >>>>> >>>>> >>>>> >>>>>But it could also mean it probes TBs in all the plies except the last 6/8. >>>>> >>>>>Meaning that if Nimzo is doing a X plies search, then the program probes the TBs >>>>>in the tree for all nodes that have a distance from the root below or equal to >>>>>X-6 (or X-8). >>>>> >>>>>I don't think that probing the TBs in the first 6/8 plies of the search makes >>>>>any sense. >>>> >>>>Do yo mean this in absolute terms or do you mean this in >>>>terms of "doing probes last few plies like qsearch is more important >>>>as doing probes in the first 8 plies?" >>>> >>>>In the first case i would disagree. in the second case i would agree. >>> >>> >>>What I wanted to say is that probing the TBs in the first 6/8 plies ONLY does >>>not make sense. >>> >>>I mean that there must be some mechanism to somehow relate the depth of the >>>probing to the depth of the search. >>> >>>If you are going to depth 25 at this time, you certainly don't want to stop >>>probing the TBs at depth 8. >>> >>>However Alex answered something that is still unclear to me which would suggest >>>that in the first 8 plies he does some kind of probe, and he does another kind >>>of probe in the next plies. But I can be wrong here. >>> >>> >>> Christophe >> >> >>That is what they do. They load the win/lose/draw tables into memory, but >>they don't have them _all_ in that format. They probe the normal tables >>early in the search where the cost is low. They probe the w/l/d tables >>everywhere else as there is no I/O required. This means that for the w/l/d >>tables, you only get a bound on the value and you could get into a never-ending >>mate in N loop. But by probing the real tables early in the tree, they will get >>the right distance-to-mate scores where it really matters... >> >>This has been discussed before. The only problem I pointed out is that if you >>do all the 3-4-5 piece tables as win/lose/draw, you _still_ need over a gigabyte >>of memory to hold the result. That is still too big, and now that we are 40 >>gigabytes into the 6 piece files, forget win/lose/draw for them. > > > >OK I see now. > >Well it's a smart trick and I guess that storing in memory the WDL TBs for 4-men >positions only would already be an improvement... > >However I wonder how many elo points they get with these WDL TBs... It's quite a >programming effort to implement them I guess. > >On the other hand, if you use the memory required to store the WDL TB for other >purposes, like extending your hash tables, maybe you get the same kind of ELO >increase? > >So I wonder if it's really worth it. > > > > Christophe Actually you get 'em for free. You just write a small driver program that will enumerate every possible piece position, do a few legality checks to keep things sane, then probe. If you get a value ==0, store a 0, if you get a value > 0 store a 1, if you get a value < 0 store a 2, and continue this for all positions. If you are sloppy you use 2 bits per position rather than 8, which is a 1/4 savings. If you are more clever, since you only have 3 states, you can put 5 positions per byte. If you want to go nuts, you can use 3 bits for every 2 positions and save a bit more, but then probing that mess becomes somewhat problematic, since the point is to be fast. :) I'm just not personally convinced of the usefulness of this since all the 3-4 and 5 piece files are 7.5 gigs. That turns out to be about 1-2 gigs depending on your compression scheme (this actually might be in error as the 7.5 gigs are compressed and I have not tried to think about how the 1.5 bit values would compress... as well? worse? better? Don't really want to think about it right now. :)) I'm not impressed with loading 1+ gigs of stuff into memory. And if you have to probe the 1.5 bit tables on disk, I would have to run some experiments to see if it actually pays off to have two sets of tables...
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.