Author: Robert Hyatt
Date: 22:00:57 09/24/01
Go up one level in this thread
On September 24, 2001 at 23:15:29, Vincent Diepeveen wrote: >On September 24, 2001 at 22:49:02, Robert Hyatt wrote: > >>On September 24, 2001 at 21:49:52, Vincent Diepeveen wrote: >> >>> >>>So you say kind of here that it is NEVER possible in your viewpoint to >>>get a 2.0 speedup when only measuring search times? >>> >>>Please give a clear statement here. >>> >>>Yes or No. >>> >>> >> >> >>OK. For an average case, which is made up of multiple positions, the answer is >>"no" unconditionally. >> >>For a single test case here and there, the answer is _obviously_ "yes". >> >>_everybody_ has reported a >2 speedup for 2 cpus on a random position or two >>out of a set. This is expected since we are dealing with randomness in the >>move ordering and random can sometimes be good, sometimes bad. >> >>Look at my DTS numbers. at least one > 2, several well below 2. >> >>Average is a scientific-looking 1.9... >> >>If you report >2.0 speedups consistently, you are simply going to get >>laughed at over and over. It is just not possible unless your serial >>search is bad. So either your results (parallel search) are bad, or >>your serial search is bad. In either case, "bad is bad". > >Define 'bad' here. Bad is any sequential algorithm that consistently produces super-linear speedups using more than one cpu. Because if this is done consistently, then there is a trivial way to make the serial algorithm run faster as well using simple time-slicing, as I have explained a dozen times... I think Knuth was the first to say this. There have been others, including myself that agree... > >'bad' relatively compared to others who all use futility pruning, >and who do recursive search, or 'bad' in absolute terms? > >I've said over and over again that i tried to improve my move ordering >in all kind of ways. I have way more code than you have in crafty. > >If i order my moves like you do in crafty, then i search a ply less. We can compare lots of things. I don't get super-linear speedups regularly. I never have. I don't know of anybody else that does either. All of us have reported anomalies, but they are rare. So the time-slicing trick won't work for me. If you are producing > 2.0, then it is trivial to speed up your sequential search... Note that I am not doing "futility pruning" in any well-accepted sense of the term. I cull losing captures in the q-search only. My N-ply search has no futility or anything else in it. The only forward-pruning I do is the result of the null-move search...
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.