Author: Vincent Diepeveen
Date: 14:23:43 05/05/04
Go up one level in this thread
On May 03, 2004 at 15:17:15, Robert Hyatt wrote: SHOW ME REFERENCE TO THE DATA PROVING IT HOLDS TRUE FOR 8 PROCESSORS. I HAVE NEVER SEEN SUCH DATA *EVER*. I HAVE ONLY SEEN DATA IT IS NOT TRUE FOR 4 PROCESSORS. YOU HAVE MY EMAIL ADRESS. I CANNOT READ ALL YOUR WRITINGS HERE OF COURSE. NOTE THAT I HAVE EMAILED YOU ALSO THE CHALLENGE CRAFTY-DIEP TO PLAY FOR MONEY A MATCH. AUCH CAPSLOCK, SORRY FOR THAT. AT LEAST YOU CAN CLAIM THAT THIS POSTING DONE IS DONE AS QUICK AS YOU USUALLY POST... >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.