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.01 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.