Author: KarinsDad
Date: 23:12:57 12/26/98
Go up one level in this thread
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 >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.