Author: Dave Gomboc
Date: 15:45:37 09/23/01
Go up one level in this thread
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. 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.