Author: Roberto Waldteufel
Date: 09:40:37 12/27/98
Go up one level in this thread
On December 27, 1998 at 02:12:57, KarinsDad 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 > Hi KD, A tablebase node is not necessarily part of a winning sequence. It is simply a node you can evaluate exactly. It will either be definitely won, drawn or lost. The trouble is, you won't know which until after the tablebase lookup (ie hard disc read), so you can't continue searching in the main thread until you have a result from the lookup because what the search does next depends on the result. That is why I was proposing having different threads to simulate a parallel search, so as to have some other part of the tree to search while the tablebase lookup is done, but I see now from Bob's post that this is not likely to be much use. The point is that the alpha-beta algorithm loses a lot of it's efficiency when parallel threads are used because information in the threads is not shared between them well enough to enable as many cut-offs in the search, so you have to search a lot more nodes. It's a pity.....:-( Happy holidays, Roberto
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.