Author: Uri Blass
Date: 07:21:44 09/19/01
Go up one level in this thread
On September 19, 2001 at 09:57:21, Robert Hyatt wrote: >On September 19, 2001 at 07:18:28, Tony Werten wrote: > >>On September 18, 2001 at 18:27:01, Robert Hyatt wrote: >> >>>On September 18, 2001 at 17:19:54, Vincent Diepeveen wrote: >>> >>>>On September 18, 2001 at 16:53:30, Robert Hyatt wrote: >>>> >>>>>On September 18, 2001 at 14:45:45, Vincent Diepeveen wrote: >>>> >>>>[snip] >>>> >>> >>>That is correct. If you can produce a speedup of > 2x, using 2 cpus, you >>>have a bug, or an anomaly position. It is simply not possible. If you >>>are _really_ doing that, you should modify your single-cpu version as >>>follows: >>> >>>search normally until you would choose to use a second process if you had one. >>>From this point forward, time-slice between two search threads. Search one >>>node on one, one on the other. That should run twice as fast, since it is >>>_exactly_ how the program really does on the SMP platform. >>> >>>And that will _not_ work unless you have either the world's worse sequential >>>search algorithm, or the world's buggiest parallel search algorithm. >>> >>>Before you label a statement as ridiculous, find me _one_ person that will >>>side with you and say that "yes, it is possible to get a > 2 speedup using >>>only two cpus on anything but anomaly positions. Find _one_ person that will >>>agree... >>> >> >>Just for fun, I'll give it a try. I'm probably wrong but maybe you can point out >>where I go wrong. >> >>To make it more obvious I'll make the numbers a bit more extreme. >> >>Vincent says that in 85% of the cases the first move is the cutoff move, that >>means in 15% it's not. Now suppose the cutoff move is always the second move and >>that it's an easy cutoff. >> >>Normally you would search the first move (say 15 seconds) then the second (say 5 >>sec) total is 20. >> >>Now 1st and second are searched parallel, second causes cutoff after 5 secs, >>first get's stopped. Total time 5 secs. 4 times faster. > > >Here is the problem. That works in 15% of the time. What about the _other_ >85% of the time? You search two moves. You only need to search the first to >get a cutoff. 85% of the time you search double the stuff you _need_ to search. >Net result: way slower. > > > >> >>Funny thing: The worse your first cutoff rate is, the bigger the speedup. >> > >True of course. And well-known. But today's programs (mine at least) >gets a cutoff on the first move 92% of the time. That leaves only 8% >for improvement. Not exactly. It is possible to get a speed improvement even in part of the 92% of the cases. The fact that you only need the first move to get a cutoff does not prove that the order of moves is optimal because it is possible that another move helps you to get the cutoff faster. Uri
This page took 0.01 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.