Author: Robert Hyatt
Date: 07:42:47 12/27/98
Go up one level in this thread
On December 27, 1998 at 02:12:57, KarinsDad wrote: >On December 26, 1998 at 06:25:26, Roberto Waldteufel wrote: > >Roberto, > >Having done several multi-threaded applications, my advice is to not create a >second (or third) thread until you actually hit the tablebase node. Better yet >might be to have a suspended second thread that gets used only when you need to >access a tablebase node. You are right, emulating a multiprocessor system will >entail non-trivial overhead (not just from the OS, but moreso within your code). >I think you'd be better off having a second (normally suspended) thread >returning the tablebase information when ready and have the main thread continue >it's current search normally. It could then go back and use the tablebase >information once the second process is finished. Of course, this would assume >that you would not hit multiple tablebase nodes. If you wanted to handle >multiple ones, you could queue them up for the second thread. > >What confuses me on your post (and this is simply due to my own ignorance on the >subject) is that I was under the impression that once you were using a >tablebase, that you had a solution to winning the game. Is the reason that you >continue searching due to the fact that you may not have a forcing line to get >you into the tablebase? > >KarinsDad > this is the key issue with probes. It is not a matter of *if* the probe is successful, because you simply don't probe unless you *know* it will be successful. Rather it is simply a matter of the reason you stop searching at this node... because it is absolutely either won, lost or drawn and there will *never* be any more searching below it. >>I can't help myself from licking my chops at the thought of all those CPU >>instructions. Suppose we use threads under Windows to simulate multiple CPU's on >>a single CPU computer. I guess that entails some non-trivial overhead, but on >>the plus side, when we hit a tablebase node, assuming we have non-blocked disk >>access capability (ie we either have NT or else have a VxD to provide such a >>facility under Win95 or Win98), we could use the Windows Sleep API call to >>simply give a time slice back to Windows while the physical disk access actually >>takes place. This time slice could then be used by the other active threads, >>thereby gaining a large number of otherwise wasted CPU instructions. >> >>Now the question is whether the saved time at tablebase nodes would be enough to >>pay for any inherant overhead in the simulated parallel search. Of course in >>positions that have no tablebase hits at all in their trees, we gain nothing at >>all to compensate for the overhead, but in an iterative deepening framework, we >>could count the number of tablebase hits on each iteration, and only call the >>simulated parallel algorithm if a previous iteration had more than some >>threshold of tablebae hits. >> >>I have absolutely no idea how great the overhead of a simulated parallel search >>would be. Has anyone ever experimented with using threads in this way? I have a >>dim recollection of reading something here several months ago about using >>threads to simulate a parallel search in order to develop and debug a parallel >>search algorithm on a single CPU machine, but I think the idea was just for >>development, with the final version intended for a multiple CPU platform. If the >>idea is not practical, please tell me, as I would not want to waste my time on a >>big experimental program that was doomed to failure from the start! If the idea >>is practical, the my next inevitable question is what is the best reference for >>parallel search algorithms, and is there any single algorithm that is considered >>the most efficient?
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.