Author: Robert Hyatt
Date: 09:02:19 11/08/01
Go up one level in this thread
On November 07, 2001 at 19:00:06, Robin Smith wrote: >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 Because including the 6 piece files we have done, there are over 50 _gigabytes_ of tables. :)
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.