Author: Robert Henry Durrett
Date: 17:31:47 05/30/02
Go up one level in this thread
On May 30, 2002 at 10:57:42, Adam Oellermann wrote: >One good reason why it won't scale as you might expect: you won't be able to >share a hash table across the motherboards (unless you have some frighteningly >fast special interconnect between them). Given how fundamental this is to chess >engines (for move ordering, eval, ETC, and so forth), you're not likely to get >anywhere near the improvement you get from (for instance) adding another CPU >into an SMP rig. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Well, my first impression is that you are talking about a concept which is different from the one I intended. I intended to have no communication at all between the individual fast processors except right at the beginning after the last move was made and right at the end, for selection of the computer's move. I realize that this "non-communication" would entail a performance hit when compared to a scheme where there was a task manager and continual communication between individual computers, assuming all else equal [such as identical processors]. As noted elsewhere, the scheme of using "independently operating" computers would permit using VERY fast computers. On the other hand, using existing 8-processor computers would be much worse due to the fact that those currently available 8-processor computers are relatively very slow. I envisioned NO sharing of a hash table. This choice is based on the assumption that the initial partitioning would be done well. But, be that as it may, there probably would not be enough time to develop an 8-processor chess computer with a shared hash table in time for the October DF/Kramnik match, . . . which is what I'm interested in, primarily. Bob D. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > >- Adam > >On May 29, 2002 at 23:19:52, Robert Henry Durrett wrote: > >>On May 29, 2002 at 21:57:35, David Dory wrote: >> >>>On May 29, 2002 at 20:44:07, Robert Henry Durrett wrote: >>> >>>>Would this Configuration Work [At least theoretically]? >>>> >>>>Perhaps all in a single box, conveniently called a “COMPUTER”: >>>> >>>>Have eight motherboards, each with one processor. Motherboards and processors >>>>would be the fastest available. Each motherboard with it’s own RAM, also >>>>fastest available. Everything optimized for use as chess engines. Chess engine >>>>software, possibly all identical, loaded into each MB/RAM/Processor. I.e. each >>>>board operates as a chess computer, independently from the other seven “fast” >>>>boards. Essentially, there would be eight chess computers all performing >>>>independently, one on each board. >>>> >>>>Have two more motherboards, not necessarily fast at all, with relatively slow >>>>processors. RAM might be not so special either, although maybe should be if >>>>used for transferring data to other processors via read/write to this RAM. >>>> >>>>The chess move gets entered into the first “slow” processor. It computes all >>>>legal two-ply [or more?] move sequences. That would not take much time, so fast >>>>processors not necessary. Then the set of possible two-ply sequences is >>>>partitioned into eight subsets, all roughly equal in size. >>>> >>>>Then the first subset is sent to the first fast board, the second subset sent to >>>>the second fast board, etc., with the eighth subset sent to the eighth fast >>>>board. >>>> >>>>Each fast board [i.e. chess computer] then finds the best move sequence of those >>>>sent to it. It does not consider any other cases. >>>> >>>>Then each of the eight fast boards sends it’s “best move,” along with any >>>>supporting data, to the second “slow” processor. >>>> >>>>Finally, the “slow” processor selects the best of the eight available moves >>>>[using the "supporting data" as appropriate] and outputs the COMPUTER’s move. >>>>If two best are precisely equal, may have to pick one by “flip of coin.” >>>> >>>>No one needs to know how many boards are in the box. [May as well be sneaky.] >>>> >>>>Incidentally, the box must have the necessary supporting hardware, such as power >>>>supply(ies) etc. >>>> >>>>If this would work, at least theoretically, could it be made to work in time for >>>>the DF/Kramnik match in October? NASA could send a man to the moon and they met >>>>their deadline, and this seems a much simpler task. Would a “can do attitude” >>>>[and $$$] get this job done in time? >>>> >>>>Bob D. >>> >>>Sorry Bob, >>> >>>You don't get much benefit out of this type of set-up. (This is very similar to >>>a "cluster", I believe). The best thing about it is that you could have each CPU >>>& board, "guess" a different answering move by the opponent, and begin working >>>on the best reply on the opponent's time. IMHO >>> >>>Because of the nature of alpha-beta, the bandwidth get's plugged. >>> >>>This is what I've always been told. REALLY would like to see it done though, and >>>thoroughly tested with excellent components. (No slow CPU's) >>> >>>Sometimes you THINK it just HAS to be (good/bad/indifferent), but you don't know >>>for stink until it's really tested. Even then, you only know with the EXACT >>>set-up you have at that moment of testing. >>> >>>Everything else is only fine speculation. >>> >>>David >> >>Thanks for responding. I was beginning to think that I was "persona non grata" >>on this bulletin board. >> >>I deliberately avoided getting into any details, at all, to keep the >>presentation as conceptually simple as possible. Perhaps that's why you saw it >>as being in the nature of "speculation." I was an engineer [Electrical, >>Aerospace, & Systems] for thirty years and have a considerable amount of design >>[& testing] experience. I really do appreciate that initial conceptualization >>is merely the very first step and that there would be a lot of detail design and >>testing remaining. I'm not sure it would take so long, though, if the right >>people were on the job. >> >>About the issue of "similarity to clusters": The suggested partitioning concept >>may distinguish this concept from the clustering concepts you are referring to. >>I don't know, since there may be more than one "clustering" concept in the >>literature and I don't know which one(s) you are referring to. >> >>About the issue of "working on the opponent's time": Once a move is made by the >>COMPUTER, then the COMPUTER could follow the identical procedure it followed >>after receipt of the opponent's move. It is like "Infinite Mode" in Fritz. >>Once a move is made, Fritz in Infinite Mode doesn't care who's move it is. It >>doesn't change anything. Fritz then goes about finding the next move, even >>though the move is for the opposite side. >> >>About the issue of "no slow computers." Yes, I included them merely to simplify >>the presentation of the concept. The tasks I showed for the "slow computers" >>would be done by one or more of the "fast" computers. >> >>About the issue of "alpha/beta and bandwidth": I really don't see how this >>concern is applicable at all in this configuration. [Help!] >> >>Please rethink the concept of partitioning of all possible two-move sequences. >>This is another case where I deliberately avoided getting into detail. The >>partitioning should be done in a "smart" manner to minimize the likelihood of >>one of the "fast" computers wasting time on moves which were no good, while >>others were working on the only good moves. I see a performance improvement by >>using this "smart partitioning." The basic concept is to arrange matters so >>that none of the eight computers would be duplicating the work of any of the >>others. >> >>Similarly, the idea that each of the eight computers would forward only one move >>[with supporting information] was a simplification made to make the concept >>presentation simple. A performance improvement might be expected if each of the >>eight computers were to forward information on several moves. >> >>There are MANY other essential details not presented. I was looking first for >>an input as to whether or not the basic concept was essentially sound. >> >>Calculation of the maximum theoretical gain from this concept is something of >>interest. I was hoping for close to an 8X improvement in effective computation >>time over a single "fast" computer. I have deliberately ignored pruning effects >>because I considered them to be "second order" and primarily at greater ply >>depths [i.e. **inside** the "fast computers."] I would not have expected pruning >>within the first two ply. >> >>Bob D.
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.