Author: Robert Hyatt
Date: 20:06:39 09/13/01
Go up one level in this thread
On September 13, 2001 at 09:01:01, Vincent Diepeveen wrote: >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! It wouldn't be getting 10 plies today. Hardware has come a long way from the motorola M68020 and 68030 chips used in the sun machines back then. > >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. > 10 years ago we had 33mhz processors and 10mbit/sec ethernet. Today we have 1.5ghz processors and gigabit ethernet. The processors are maybe 50 times faster. The network is way over 100X faster. >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. If you give me a cluster with a theoretical speed of 1B nodes per second, I'll bet I can get at _least_ 1/10th of that and probably closer to 1/3. That is a huge speedup. > >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! As I have said before. First, there are ways to share hash tables. Second, there are incredibly fast network interconnections like the Clan stuff I have here. 1.25 gigabits per second, bi-directional, .5 microsecond latency. That isn't a _lot_ slower than PC memory speeds.
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.