Author: Vincent Diepeveen
Date: 15:32:50 09/23/01
Go up one level in this thread
On September 22, 2001 at 14:14:48, Dave Gomboc wrote: >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. The average test done here at CCC is 10 to 20 seconds a move. Even the new try to make a WACII the dudes test at most at 1 minute a move. So you're kind of wrong here. Most tests in ICCA and advances in ICCA are based upon anything under or equal to 8 ply. I can only remember a single article 'crafty goes deep' where some deeper searches were done. > >> 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.06 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.