Author: Robert Hyatt
Date: 14:55:34 03/30/01
Go up one level in this thread
On March 30, 2001 at 17:36:45, Christophe Theron wrote: >On March 30, 2001 at 15:23:38, Robert Hyatt wrote: > >>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 understand that you do not need to rebuild the tables and you can copy the >content of existing tablebases. > >What I find a little bit complicated is to deal with all kind of symetry and >piece enumeration stuffs. OK, that's not so complicated, but I find the work a >little bit boring. :) > >I prefer to work on search or position evaluation... > > > >>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... > > >But if they just compress the 4-men tables it's not so big. > >As far as I know, all 3 and 4 men TBs are only 30Mb big. If you can compress >them by only 50%, then it's only 15Mb to store in RAM. > >So maybe it is interesting with 3 and 4 men TBs. > >On the other hand, if you have 30Mb available, you can just preload the standard >Nalimov TBs into the disk cache, so I really don't know if WDL TBs really make a >difference. > > > Christophe I agree. Note that 30mb _is_ compressed. And I doubt it can be compressed much further since it already uses a very efficient indexing scheme, and then a TB-specific compression algorithm on top of that. However, here I prefer to let technology win. Rather than reducing 30mb to 8mb or whatever, I will just wait until 30 megs costs no more than 8 megs does today then I don't have to worry about anything cute. :)
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.