Author: Vincent Diepeveen
Date: 06:01:01 09/13/01
Go up one level in this thread
On September 12, 2001 at 13:10:24, Robert Hyatt wrote: >On September 11, 2001 at 22:49:49, Vincent Diepeveen wrote: > >>On September 10, 2001 at 18:13:51, Dan Andersson wrote: >> >>>I know of at least one search method that would fit perfectly on this kind of >>>machine. I recently had the pleasure to be able to run an old Othello program of >>>mine on a brand new NUMA machine. Implementing a published algorithm. I was >>>surprised to find a near linear function speedup to the number of processors >>>close to one to one, up to all sixtyfour available. There was of course a small >>>slowdown at each node but all in all it was a profitable tradeoff. >>> >>>MvH Dan Andersson >> >>Unless that 'lineair speedup' is like 0.01 or something so very small >>i don't believe a word of it for computerchess. >> >>We search that deeply nowadays that getting a good speedup at a cluster >>is nearly impossible. I do not know of course how important hashtable >>is for othello and i do not know the quality of other programs you compare >>it with. >> >>AFAIK othello was nearly solved, is it? >> >>How would you distribute hashtable on a machine with such a slow communication >>speed like this machine? > > >1. I don't believe that reasonable speedup is impossible on a cluster. I don't >believe a cluster can do as well as an SMP machine, however. > >2. Distributed hashing has been shown to work. It makes the program design >a bit more complex, because when you need to fire off the hash probe as soon >as possible, and you need to search as though there will be no match. But if >a remote machine returns a hash entry a bit later (1/2 node later or more) then >you can _still_ use the information belatedly and take whatever action is >needed. Since a typical middlegame gets < 20% hash hits, this means that in >more than 80% of all nodes you have no problem anyway. > >3. There have been successful cluster chess machines. Phoenix is one. It >wasn't as good as an SMP implementation, but it was definitely better than using >a single CPU. With all respects for the old pioneers, using nowadays algorithms that's compeltely unusable. Phoenix when run today would be blown away to the left and right, when just talking about search! I mean getting 10 ply is no longer impressive! The speed of processors nowadays is relatively faster than the communication speed. As you indicated yourself a major problem is the time needed to fire up a threat. So if you would delay transposition table hits, then it takes half a second for each entry *at least* to get result back to the thread that handles this. The problem is running more than 2 threads at a dual. Note that the speed of most software programs at huge hardware never was impressive. I mean crafty gets dual at an AMD 1.5M nodes a second, now imagine you have it running at a cluster from 500 nodes. That's nearly a billion nodes a second on paper. In reality most 500+ processor programs get a few million nodes a second. That's a factor 100 at least difference. That factor 100 in nodes a second difference is a *major* problem when talking about distributing hashtable. What happens usually is that dudes then first slowdown their program a factor 100. Logically that solving the problem is easier then! All models seen so far for clusters simply do not work and are tested in such a poor way that there is in no means proof that it's possible to get a decent speedup at them!
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.