Author: Robin Smith
Date: 16:00:06 11/07/01
Go up one level in this thread
On November 06, 2001 at 18:21:06, Robert Hyatt wrote: >On November 06, 2001 at 14:10:50, José Carlos wrote: > >>On November 06, 2001 at 13:54:02, Joshua Lee wrote: >> >>>Tablebases are too slow. TB's slow down search to a rediculous point and will >>>make a 1Ghz machine think it's a P-90. >>>Is there any work being done to improve function of probing or what can be >>>changed about tablebases or anything that works with the tablebases to change >>>this? I don't have SCSI but i have two drives which are amongst the fastest IDE >>>drives you can buy 8.2 and 8.9ms access time, you can get SCSI drives that hover >>>around 4.9ms and up past 10,000 rpm. This i believe would'nt change the Search >>>hit. This probably has more to do with the first time the TB's are Accessed the >>>Program continues to Look Even if it didn't find anything to help so at ply's >>>1-20 Which will come by fast in the endgame are bogged down and now take much >>>longer. >>> >>>What exactly is the program looking at and how are the positions stored? I can't >>>imagine a bunch of EPD's for KPPKPP. >>>I would think that the compression and how the program looks for the position to >>>be it's Sore Spot. >> >> I don't know the answer to your question, but tablebase access can kill your >>program's performance if you probe too much, and can improve a lot if you probe >>only when you need it. >> So once you get it working, you have to make it work fast. Not easy at all. >> >> José C. > >If he was talking about writing his own program, the first trick to notice >is that if you reach N pieces, and you have N piece tables, you probe _only_ >following the capture that takes you down to N pieces. If you don't hit there, >you do _not_ probe at every position past that point as you _still_ won't have >that table and the overhead is wasted. You probe only after a capture or pawn >promotion, and nothing else. > >Once you get that right, then you start limiting the depth you probe at, which >directly controls how many I/O reads you do. The more you limit the probe >depth, the less the performance penalty. You have to strike a balance between >speed and probing... Overboard in either direction hurts. In this day of inexpensive computers with 3GB RAM, why not just load the relevant TB's into RAM and probe there? Robin
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.