Author: Robert Hyatt
Date: 07:10:12 10/23/01
Go up one level in this thread
On October 23, 2001 at 09:24:03, Ratko V Tomic wrote: >>>distance-to-mate is implicit in the best-move table, it just >>>takes a bit of calculation >> >>That was my point. A normal EGTB hit is the end of the work. This >>will require another 100 EGTB reads if it is a mate in 50. That >>would absolutely crush performance and weaken the program to the point >>it would be far stronger without the EGTB's that have to be used like that. >> > >After you follow through with these 100 reads you have computed >automatically the 100 distance-to-mate values, not just the one >which is the farthest from the mate. Since these are more relevant >for the game you're playing than general purpose distance-to-mate >values, one would keep the "wasted" 99 values in expanded form, >1 lookup away. They'll likely turn up in the searches shortly. I don't see how. I will never probe them most likely. Because once I get a TB "hit" I don't search down that branch any further, period. And that one TB hit now becomes 100X as slow as the original DTM TB hit... Try modifying the probe code to do another 99 random I/O operations into a compressed TB for each successful probe, and notice what that does to search performance. The single probe is a performance problem already... > >So, you're roughly getting one distance-to-mate value per one >lookup, except that lookups are batched up, you can't just >do one at a time. Considering the reduced memory paging effect >of batching up similar tasks, it may end up gaining not losing >the time (just as buying groceries for the rest of the week, >while you're there, saves you time & cost compared to buying >only what you need at the moment; it's the special case of >the economy of concentration of efforts/specialization). > Not really. Because once I get a TB hit the tree is cut off at that point. I won't be probing at _all_ at nodes below that point because they won't be searched. >Considering also that using the best-move you may be able to >fit couple times more table information on any given disk >or RAM size you have available, it is less than obvious that >distance-to-mate has any advantage at all (and it may well be >worse) regarding the net playing strength. All the TBs so far use 8 bit values. So there is no savings on the "best move" approach until we get to the 6 piece files with mates > 127... And once we get there, this performance hit will be a killer. There is a huge difference between probing 4 piece files and 5 piece files, performance-wise. Because as the number of pieces reduces, the tree becomes less bushy and deeper. As you back up to 5 piece files, the tree becomes bushier. And for 6 piece files it is bushier still. Probe speed becomes critical.
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.