Author: Robert Hyatt
Date: 11:12:05 08/22/02
Go up one level in this thread
On August 22, 2002 at 11:34:53, Gian-Carlo Pascutto wrote: >On August 22, 2002 at 11:07:57, Robert Hyatt wrote: > >>I'm not handwaving at all. Why don't you take crafty on a 1 processor box >>and then compute its branching factor. Then do the same on a 4 processor >>box using only the time required to search. The numbers will track quite >>well. In fact, you can _not_ use the parallel nodes searched to compute >>a real branching factor for obvious reasons... > >Crafty != DT. Moreover, later in this post you say that it's an >apples to oranges comparison. Again I'm missing some consistency here. > >>As I have also said, until you understand their parallel search in particular, >>don't let a few months of fiddling with a primitive parallel search algorithm >>color your thinking. More processors in their case (more hardware processors >>not more software processors) does _not_ give them trouble "kicking them in." >> >>Their search doesn't work like yours. Not anything related, in fact... >> >>> >>>I still haven't seen this sufficiently addressed, so I will get some more >>>data about it myself. >> >>Read his thesis. Then you will understand why you are comparing apples to >>oranges when you compare a software search like you are doing to what they >>are (were) doing... >> >>The problems and issues are completely different... > >Whether I have read their thesis is completely irrelevant to the very basic >fact that you cannot calculate a branching factor when you're looking at >*times* in a situation where the *nodes per second* is variable. > >The traditional idea of a branching factor becomes meaningless in this >situation, so quoting 4.0 as theirs is just as meaningless. It is better than a wild guess. And I can certainly prove that for my program, at reasonable search depths, the number of processors is not an issue that affects the branching factor... Nodes is a red-herring because the more processors you use, the more nodes you search in total as well. But who cares? What I care about is that if I am going to do a depth N+1 search, how long is it going to take me, compared to the depth N search I just finished. And _that_ is the classic definition of "effective branching factor". "real branching factor" is probably meaningless in a parallel search because it doesn't tell you anything at all that is useful. But the time multiplier for the next iteration _is_ useful and important. ANd that is _exactly_ what I calculated from the logs. And so long as their logs say that a 12 ply software search requires 3.9X longer than a 11 ply software search, I would call _that_ effective branching factor to be 3.9... any way you care to measure it. > >-- >GCP
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.