Author: Robert Hyatt
Date: 15:03:39 05/05/04
Go up one level in this thread
On May 05, 2004 at 17:23:43, Vincent Diepeveen wrote: >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*. Not my problem. I've certainly given the numbers. I can post some data from an 8-way opteron. If I recall the speedup was 5.6X. Lets see... A linear fit to that would be perhaps: 1 + 4.6 / 7 = speedup = 1 + (NCPUS - 1) * .657 Or, in rough numbers, .657 is close to .7. Since this is a straight-line approximation to a function that is likely not a straight line... > >I HAVE ONLY SEEN DATA IT IS NOT TRUE FOR 4 PROCESSORS. You have seen data? You have not seen data? I don't know what the above means, and _really_ don't care. > >YOU HAVE MY EMAIL ADRESS. I CANNOT READ ALL YOUR WRITINGS HERE OF COURSE. You will get no email from me, fraud... It's a waste of time. Been there. Done that. Got the T-shirt. Not going there again. > >NOTE THAT I HAVE EMAILED YOU ALSO THE CHALLENGE CRAFTY-DIEP TO PLAY FOR MONEY A >MATCH. Just pop over to ICC and play. Be cheaper for you. I don't bet on chess games. Fortunately _I_ am a bit more mature... > >AUCH CAPSLOCK, SORRY FOR THAT. > >AT LEAST YOU CAN CLAIM THAT THIS POSTING DONE IS DONE AS QUICK AS YOU USUALLY >POST... But with much less thought behind it apparently... > > >>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.