Author: Robert Hyatt
Date: 09:46:23 09/18/01
Go up one level in this thread
On September 18, 2001 at 11:54:45, Vincent Diepeveen wrote: >On September 18, 2001 at 11:07:27, Gian-Carlo Pascutto wrote: > >>On September 18, 2001 at 09:10:02, Vincent Diepeveen wrote: >> >>>Well if no one here manages to do that, who am i to say that the >>>remainder of this algorithm is worth trying? >> >>Perhaps just noone bothered? >> >>>Which means that APHID already says who has to search what before relevance >>>of parallel splitting has been indicated. Considering that nowadays we >>>use nullmove bigtime, this makes APHID completely outdated, because >>>it in short doesn't wait at all! >> >>They Crafty they used had nullmove R=2. Nowadays most people (I know >>you don't, but you aren't everybody even if you continously think so) >>use R=2/R=3. I'm pretty sure that isn't going to make the difference >>between usefull and useless. > >All testresults they published are based upon 5 to 8 ply searches >and based upon a program called TheTurk. No mention of crafty speedups, >and if they are then it's still 5 to 8 ply. > >Who cares for 5 to 8 ply speedups in the year 2001? > >My speedup is horrible at 7 ply, no kidding, but look how my speedup is >at bigger depths! My speedup is no different at depth=7 than it is at depth=10. It is a bit more efficient at deeper depths, but not 2x. Or 1.5x even. Here's some data: searched to depth=9. I can't really time depth=7 searches as they take a few hundredths of a second and that is not very accurate. 1cpu: 2.80 4cpu: 1.02 1cpu: 3.92 4cpu: 1.39 Now for 12 plies: 1cpu: 87.00 secs 4cpu: 21.08 seconds 1cpu: 100.00 secs 4cpu: 40.17 secs In each of the two positions tested above, I ran the thing with one processor and then with 4 processors. Everything else remained exactly the same. The first position is kopec 22, the second is kopec23. Chosen at random for no good reason. I can do perfectly fine with very short searches. Or very long searches. But remember that you and I are not splitting the tree in the same way, because I can split at the root when it is reasonable to do so. that helps the speedup quite a bit. > >I don't want to crack down results from the APHID team back in 1996, >but we must clearly realize that what worked back then is NOT going to >work in 2001 anymore! Again, would you care to make a small wager? They got about 33% efficiency on their hardware. I think that can be improved on with some more work. They only wanted to get it to work, not work very efficiently. And I think that 50% efficiency is doable. And on my giganet hardware I think that well beyond 50% is very doable. > >>>This refers to the fact that YBW for each node needs a result for the >>>first move first before splitting other moves. Now this is of course very >>>true, but this directly also shows that APHIDs branching factor is by >>>definition bigger than algorithms which use YBW. >> >>I don't think they make any claims that their branching factor is better >>than YBW. Would seem pretty silly to me. But then again, YBW probably >>gets killed in different ways when having to deal with slow interprocess >>comms on a cluster. YBW doesn't exclude clusters. In a tree search, the number of "split" operations has to be constrained so that the overhead of splitting doesn't dominate the work done in actually searching the tree. I control this in Crafty by limiting how near the tips of the branches I can split the tree. For a distributed approach, I intend on a second bound, which limits distributed splits even more severely, because the overhead is going to be higher in net communication/latency. I think the difference between myself and Vincent is that I am in the business of trying to find out _how_ to accomplish something, no matter how difficult it might seem at first glance. I don't assume everything is impossible if I haven't done it myself. I assume everything is possible, until I prove that it can't be done by trying every possible alternative I can think of. IE I would rather drive a nail using a hammer. But I have done it using pliers, a wrench, a rock, a screwdriver handle, and even a C-clamp. It just takes a bit more thought and work, but it isn't impossible. Now nails are being driven by compressed air, EM impulse, blanks in a gun using the nail as the projectile, etc. All probably thought "impossible" 40 years ago. >> >>-- >>GCP
This page took 0.07 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.