Author: Dave Gomboc
Date: 11:14:48 09/22/01
Go up one level in this thread
On September 22, 2001 at 13:26:38, Uri Blass wrote: >On September 22, 2001 at 12:42:54, Dave Gomboc wrote: > >>On September 22, 2001 at 12:06:36, Uri Blass wrote: >> >>>On September 22, 2001 at 10:05:58, Robert Hyatt wrote: >>> >>>>On September 22, 2001 at 00:48:21, Uri Blass wrote: >>>> >>>>> >>>>>I do not express an opinion about the possible speed improvement that you can >>>>>get from parallel search today but >>>>>I do not see that the rest is already there. >>>>> >>>>>1)The fact that you need 2 minutes to implement R=3 in Cray blitz means nothing >>>>>if you did not test R=3 when you tested the speed improvement from parallel >>>>>search. >>>> >>>> >>>>I don't know what you mean here. In the Cray Blitz papers, I used R=1. That >>>>was what I used in the normal program. I have also reported here (many times) >>>>on the speedup for Crafty. Which is right in line with Cray Blitz. >>>> >>>>Null move has _nothing_ to do with parallel search efficiency. I have data >>>>from Cray Blitz with _no_ null-move. With R=1. And with Crafty with >>>>R=2 and R=2~3. There is no difference in the performance that I can find. >>>> >>>>So this entire discussion leaves me wondering just exactly what he is talking >>>>about. >>>> >>>> >>>> >>>>> >>>>>2)Vincent is right that the machine is hell slower than nowadays single cpus >>>>>because he talks about Cray blitz from 15 years ago and not about the latest >>>>>cray blitz that can search 7M nodes per second. >>>> >>>>15 years ago would be the YMP. That is not "hell slow". The machine had >>>>8 cpus at roughly 200mhz although that is not the way to measure the speed of >>>>a machine that can produce multiple arithmetic results in one clock cycle. >>>> >>>>I'd take that old YMP, circa 1986, over _any_ PC today for pure >>>>number-crunching. >>>> >>>> >>>> >>>> >>>>> >>>>>I understand that his claim is about long time control and the only way to test >>>>>if he is right is to take a lot of positions from games when the machine changes >>>>>it's mind after a long search and to compare the time that it needs >>>>>to do it without parallel search and the time that it needs to do it with >>>>>parallel search when the hash tables are the same. >>>> >>>> >>>>His claim is simply nonsense. I have explained why already. If he can produce >>>>a speedup of > 2 with 2 processors, then using two processes on a single-cpu >>>>machine will produce a speedup > 1. The proof is trivial. And the concept >>>>is ridiculous. >>>> >>>> >>>> >>>> >>>> >>>>> >>>>>I have positions when Deep Fritz changed it's mind after a long search from my >>>>>correspondence games but I have not multi processor. >>>>>If people are interested in testing it I may send them my positions >>>>>and they may use them in order to test the speed improvement of Deep Fritz from >>>>>parallel search. >>>>> >>>>>I agree that speed improvement of more than being 2 times faster from 2 >>>>>processors means that it is possible to improve the program when it is using 1 >>>>>proccesor. >>>>> >>>>>Uri >>>> >>>> >>>>Which means the test is simply invalid. The sequential search has to be fixed >>>>first. >>> >>>It means that the test is an important test because if the 2 processors are more >>>than twice faster than one processor for some programs then it is clear that >>>there is a room for improvement in the sequential search in the future(it is >>>possible that there is a room for improvement at long time control but the >>>programmers simply did not care for that because they care only about tournament >>>time control). >>> >>>It is also important for buyers to know it because if Deep Fritz with 2 >>>processors is more than twice faster than Deep Fritz with one processor at long >>>time control(I do not claim that it is the case) then it means that 2 processors >>>can be more important for correspondence games. >>> >>>Uri >> >>It isn't that there is room for improvement in the sequential search "in the >>future", it's that there is room for improvement in the sequential search >>_immediately_. > >If programmers do not care about correspondence time control and if the >immidiate improvement is only at long time control then from their point of view >the improvement may be relevant only in the future. Parallel speedup is for analysing asymptotic behaviour, not behaviour up to a certain, short amount of time. > Now, if that improvement isn't made, then you're testing a good >>parallel implementation against a poor sequential implementation, so your >>speedup value is meaningless. >> >>Dave > >The speedup value is not meaningless because it is possible that the cutomer >need to choose between poor sequential implementation and good parrallel >implentation so from the customer's point of view it may be important to know it >before deciding if to buy a machine with more processors. Parallel speedup is a scientific concept, used when reporting analyses of parallel search performance. What form of product is shipped to a chess software program customer is quite irrelevant. Dave
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.