Author: Robert Hyatt
Date: 12:17:15 05/03/04
Go up one level in this thread
On May 03, 2004 at 14:10:34, Vincent Diepeveen wrote: >On May 03, 2004 at 13:03:16, Sune Fischer wrote: > >>On May 03, 2004 at 11:13:11, Vincent Diepeveen wrote: >> >>>On May 03, 2004 at 10:53:19, Robert Hyatt wrote: >>> >>>>On May 03, 2004 at 10:19:46, Sune Fischer wrote: >>>> >>>>> >>>>>>I don't see any at 8. I don't personally have access to a 16-way box yet so I >>>>>>can't say anything there. But there is nothing that really makes null-move hurt >>>>>>parallel search... >>>>> >>>>>Couldn't it be, that nullmove hurts scalability in much the same way alpha-beta >>>>>"hurts" parallel search compared to minimax? >>>> >>>>I don't see how. It might make _some_ positions more unstable, and unstable >>>>positions hurt parallel search. But it also makes other positions more stable. >>> >>>What a nonsense. "i don't see how." >>> >>>it is very clearly proven. For everyone doing parallel research it is *trivial* >>>that more unstable trees are harder to split. >> >>Yes I think that is trivial too, but what is not so trivial is if nullmove >>causes these unstable search trees. >> >>>Further you must wait *longer* now to split because you first nullmove and must >>>search another move before splitting. >> >>Yes, but wouldn't this result in some processors running idle? > >It sure will. > >So there is 2 possible explanations why it is not performing the same. there is >hard data that there is a signficant difference measured in a scientific correct >way. > >And from the results we know that crafty definitely doesn't lineairly scale in >speedup going from 1 to n, like his article in journal of ICCA/ICGA suggests. I have challenged you to cite that "imaginary paper" you have mentioned. No such paper exists. No such claim has ever been made, other than the fact that I have said that the formula I have quoted has held thru 8 processors and I have posted data showing that. I've not claimed that it goes beyond 8 as I have never had access to a larger machine for anywhere near enough time to thoroughly test and measure the results. I'll leave it to you to do all the fabrication. Starting with the JICCA paper you have _totally_ made up... My only parallel search paper in the JICCA was the DTS paper. I did (with Tim Mann) write the lockless hashing paper but that had no parallel search data whatsoever. So. Man enough to admit pure fabrication about "the paper"? Or man enough to provide a formal citation giving journal number, date, pages and title? Or chicken enough to again run and hide when caught making up something yet another time??? > >Also him denying that there is shitzero difference in speedup between using >nullmove and not using it (and searching fullwidth) is clearly not true. Never said "shitzero". Said "not significantly different". Big difference for those that can read... 3% in one test. 10% in another test. Not significant in the terms you needed to justify _your_ poor results... > >>>>I don't see why, unless you form the hypothesis of "forward pruning makes move >>>>ordering _worse_." That's the only wat this could happen... >>>> >>>>There are obviously "issues". Forward pruning tosses moves out. So at any node >>>>you will have fewer branches to search than in a normal (non-pruning) program. >>>>But if you don't require that all processors always work at the same node, this >>>>should not be a problem. IE Crafty searches endgames just as efficiently as it >>>>searches complex middlegames, from an SMP perspective... >>> >>>In endgames you search in general bigger depths. So on average the trees that >>>are there after you split are bigger. Bigger depthleft means less overhead and >>>more efficient parallel search. >> >>That sounds logical, but I think splitting overhead << parallel search overhead, >>so there must be another explanation too. >> >>I seem to recall some numbers from Crafty, that a split is basicly a copy of a >>few kilobytes and a split happens a few thousand times a minute. This would >>accumulate to 1 second CPU time? > >It has an exponential effect of course. The more cpu's the more it hurts. > >>-S. Utter poppycock. Why don't you first study how/when I split, +then+ make up your information. Wait. It doesn't matter. You make it up no matter what...
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.