On Tue, 2008-08-12 at 09:15 +0200, Gian-Carlo Pascutto wrote: > > On Mon, 2008-08-11 at 20:39 -0700, David Fotland wrote: > >> Uct also has the advantage that it is much easier to use with multiple > >> CPUs. I know parallel alpha-beta exists, but my evaluation function is > >> not designed to be thread safe. If I put a big lock around it, there > >> will be almost no SMP scaling, since almost all the time is in the > >> evaluation, not in the search. > > > > This is not the case with alpha-beta. With additional processors, > > alpha-beta always does wasted work, and the more processors the more > > wasted work. It still always benefits from additional CPU's. > > I don't see how anything you said relates to what David said.
You didn't quote was I responding too. He said something about it being easier to do a parallel search. > > Aside from that, it's not theorethically necessary for alpha-beta to do > wasted work (although it will in practise), and more CPUs can make the > program worse on any practical architecture (mostly due to locking and > memory bandwidth). What??? I think you need to catch up on theory. A parallel alpha beat searcher will always do some extra work that a serial searcher won't do. You cannot expect to get a 10X speedup with 10x more processors. I'll find a paper somewhere for you to read when I get a chance. You are right that memory and locking hurts too, but even if you could idealize this away, with a simulation for instance, you are going to have some processors have to abort work because a beta cutoff has invalidated the search some thread is doing. It's possible sometime to get what is called a super-linear speedup but that is an accident. It's like changing your move ordering, it may help 1 position a lot but hurt others. I have seen > > I think any argument which is based on a state-of-the-art alpha-beta > searcher being different from a state-of-the-art UCT searcher will run > into severe problems sooner rather than later. > _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
