Author: Robert Hyatt
Date: 13:13:39 04/02/01
Go up one level in this thread
On April 02, 2001 at 16:05:36, Paul wrote: >On April 02, 2001 at 15:30:15, Dann Corbit wrote: > >>On March 30, 2001 at 14:49:09, Christophe Theron wrote: >>[snip] >>>I'm also using this condition (capture && nbpiece<=5) and I guarantee I get the >>>hard disk working real hard in endgames positions. >>> >>>The result on endgame test suites was a real disaster with this condition only. >>>So I added a condition not to probe when too close (and beyond) from the >>>horizon. >>> >>>Then I also added hand crafted endgame knowledge to decide in which cases a >>>probe is useless. >>> >>>The result is that Tiger is hardly slower (in NPS) in the endgame, but still >>>benefits from TBs. >> >>What about shifting caches sizes in endgame? >> >>E.g. suppose you have 256 megs for cache/hash/whatever. >> >>If you have only one or two pawns left, you don't need a giant pawn hash. >>Instead of searching 16 plies deep innacurately, it might be a lot better to >>reorganize the cache/hash strategy, and give a very large tablebase cache. If >>you only have seven total chessmen on the board (for instance) I suspect you >>will mostly be hitting the same tablebase files over and over. So if you make a >>large cache for them (or perhaps even memory map them completely) it might mean >>a big speedup for endgame searching. >> >>Seems like it might be worth an experiement anyway. >> >>Try some different curves as a function of how sparse the board is and what is >>on it. >> >>Make a table with fields something like this: >> >>| Total Chessmen | Total Pawns | Hash | Pawn Hash | EGTB Cache (4) | EGTB Cache >>(5)| >> >>Table entries are the outcomes of the searches. >> >>And then run an experiment and see how it turns out. >> >>Maybe you have already done so. > >But I don't think you can change tb cache size "on the fly", if that's what >you're intentions are. You have to reinit the tables after that, and that takes >a long time. So it isn't possible during game play. But maybe I'm mistaken ... > >Paul For pawns you could do it. It would mean taking each pawn hash entry and relocating it to the right place. And about 1/2 the entries would have to be trashed if you cut the table size by 1/2... The real transposition table would be a bigger problem. But then there is no reason to reduce it anyway since the EGTB results should end up in there, and _that_ is where we really want them anyway since that is the fastest thing to probe.
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.