Author: Heiner Marxen
Date: 13:40:38 04/02/01
Go up one level in this thread
On April 02, 2001 at 16:13:39, Robert Hyatt wrote: >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. I'm not so sure that this is always correct. When we throw enough cache memory at the EGTBs, such that cache misses become rare enough, EGTB probes will be fast on average. At some point they can be fast enough that it is worth it. Another point is, that the cache built in to the EGTB software does use much less memory than the normal cache for each stored position. It _may_ be that the available memory is better used this way, in which case it may not be the best idea to store these results also in the normal transposition table. There are several tradeoffs involved, here. I'm not at all sure, what is the best choice under what circumstances. Some modeling and some experiments seem to be necessary to know better. IMHO. Heiner
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.