Author: Dann Corbit
Date: 12:30:15 04/02/01
Go up one level in this thread
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.
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.