Author: Robert Hyatt
Date: 11:08:40 08/22/02
Go up one level in this thread
On August 22, 2002 at 11:28:35, Gian-Carlo Pascutto wrote: >On August 22, 2002 at 11:04:32, Robert Hyatt wrote: > >>Keeping the processors busy (the chess processors) was not an issue of >>"how many are there"? It was an issue of balance between the speed of a >>chess processor and the SP2 that was "feeding" it. > >Each SP2 had to feed several processors, so you are already contradicting >yourself here. Whether or not the SP2 can keep up depends directly on how >many chess chips it's talking to. > I'm not contradicting anything at all. DB1 and DB2 used the same number of SP processors. DB2 doubled the number of chess processors. Do you _really_ think it is harder to send out 16 positions to search than it is to send out eight? I don't. Their search didn't do this silly split stuff at all, the software just searched up to a "wall" and then spit the positions out to the chess processors as fast as they could take them (one thread) while the other thread collected results and handled the alpha/beta bookkeeping. Done like this the search had no trouble whether it was talking to 1 DB processor or 16, other than the minor overhead of sending messages and getting results, which was easily "hidden" by interleaving... And no, how many chess chips is _not_ the issue. The SP2 can produce positions to search at any speed you want. You want them to be produced slowly? Just stop the software search at ply=3 and let the hardware search to ply=X. The SP2 spends all its time waiting? Search to ply=4 on the SP2 and then do an X-1 ply search on the hardware. You keep playing this game until you find the right software/hardware depth to make it work. You have to remember that there is a symbiotic relationship here however. When you reach the perfect balance point, and then go one ply deeper on the software search, you produce positions faster. You therefore have to go one ply shallower on the hardware so that it can keep up. DB was always optimized to do as much as possible in the software search, because that was the part of the search that was "smartest" and also the part that was easiest to tune. But more processors is _not_ a problem in that environment. Not a problem at all... Which is quite unlike the problems you are seeing in PVS of course. >I can futher quote from the paper that they couldn't generate enough >parallelism in the early iterations to all chips busy, but you >have the paper as well, so you already know that. Yep. But early != 7 or 8. Early = 1, 2, etc... I have the same problem in Crafty. But by the time I search one second, those problems are long gone... > >-- >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.