Author: Vincent Diepeveen
Date: 03:36:58 07/20/99
Go up one level in this thread
On July 19, 1999 at 18:27:48, Robert Hyatt wrote: >On July 19, 1999 at 16:04:31, Vincent Diepeveen wrote: > >>On July 19, 1999 at 10:53:44, Robert Hyatt wrote: >> >>>On July 19, 1999 at 09:53:36, Vincent Diepeveen wrote: >>> >>>>On July 18, 1999 at 13:05:23, Francis Monkman wrote: >>>> >>>>> >>>>>On July 18, 1999 at 12:56:35, Robert Hyatt wrote: >>>>> >>>>>>The idea sounds attractive, until you realize that the game tree search is >>>>>>an exponential problem, not a linear one..... That makes it _very_ difficult >>>>>>for such a task to be done on computers... >>>>> >>>>>But why not treat the computers as nodes in a tree, with sub-delegation >>>>>software? (Just a thought -- but I built a working parallel audio synthesizer >>>>>out of multiple TMS99000s back in '84, so I've been 'thinking parallel' for a >>>>>while -- though not in chess. That's why I thought of you. Hope you don't mind) >>>>> >>>>>Say the machines are in a pool. Starting from root, one machine picks the next n >>>>>(=number of legal moves) machines' addresses. Then they in turn pick 'em off the >>>>>stack, and so on. Crazy? >>>>> >>>>>Francis >>>> >>>>Sounds like a deep blue parallellizing approach :) >>>> >>> >>>I don't see where. DB uses _all_ processors on _every_ move. For any ply-1 >>>move, the first 4 plies (one move each) are searched by one cpu. At this >>>point the tree is split among _all_ the SP processors. Each processor then >>>steps thru 4 plies (4 moves) and then uses its own private set of chess >>>processors to search stuff there in parallel. And it gets a lot more complex >>>after that as Hsu has a lot of 'pre-search' tricks to keep things busy... (See >>>his thesis for details). >>> >>>DB's search is as good as anything we are doing when you use that many >>>processors. It probably is better. Using 4 is not _nearly_ as hard as using >>>500. >> >>Right, that's why i'm using nullmove. >> > > >You lost me. What does null-move have to do with anything here? I did a >restricted null-move in CB. Have been using a variable-null-move search >in crafty for several months (R=3, R=2, R=0 depending on what is going on >in the search). And it didn't impact my parallel search decisions at all. nullmove and only a single SP computer would've been enuf to save IBM a few hundreds of million dollars :) >>> >>> >>> >>>>Well Francis, i fear it's a bit off reality. >>>> >>>>Deep Blue had a similar approach: >>>>first 4 ply: 1 SP processor >>>>ply 5..8 : 30 SP processors >>>>ply 8..12 : 480 hardware processors >>>> >>>>above is a similar idea, also not working that well. >>>> >>>>There are great dependancies: after first move has been searched one >>>>can efficiently give other processors a job. Till then they're doing >>>>nothing (assuming game start). >>>> >>>>example problem in your approach: if a processor finds somewhere that it >>>>wins material, then isn't it a shame in your approach that they all >>>>have done work for nothing, as they all are searching the same gamespace!
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.