Author: Vincent Diepeveen
Date: 16:33:42 09/23/01
Go up one level in this thread
On September 23, 2001 at 18:45:37, Dave Gomboc wrote: >On September 23, 2001 at 17:46:28, Vincent Diepeveen 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_. 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. >> >>This is utterly nonsense. > >It is _not_ utter nonsense! It is not possible to have superlinear speedup for >a parallel algorithm of the _best_ sequential algorithm for the class of >universal turing machines. I'm not going to argue you about it further. >Hopefully your examiners will ask you about this, then correct you, when you are >defending your thesis, if not sooner. Thesis? comon you think i'm so stupid to publish what i did? You think what i made was made and based upon one afternoon experiment, like all the other parallel numbers in ICCA are ? >Dave
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.