Author: Vincent Diepeveen
Date: 08:16:35 09/05/02
Go up one level in this thread
On September 05, 2002 at 11:01:34, Robert Hyatt wrote: Your article does mention something else. it mensions see text as also produced here. It says *nothing* on pondering. It is your word here which says it. And i don't believe your word at all. You also said in a conversation as shown here that the search times were accurate and the real search times for all testoutputs, which by now is obviously a lie. The whole article is a big lie with regard to the outputs simply. Your cray blitz thing has an unknown speedup simply. The fact that the speedup which is claimed is 2.0 though you say it is impossible to get > 2.0, whereas it is easy to show proof it is possible to get > 2.0, but not a single speedup of yours is > 2.0, because you of course couldn't imagine it either before you wrote the article, that says enough. >On September 05, 2002 at 10:12:11, Vincent Diepeveen wrote: > >>On September 04, 2002 at 15:01:55, Robert Hyatt wrote: >> >>>On September 04, 2002 at 14:49:53, Vincent Diepeveen wrote: >>> >>>>On September 04, 2002 at 14:24:47, Robert Hyatt wrote: >>>> >>>>With YOUR method it is very easily possible to get always >>>>> 2.0. >>>> >>>>The easy case is a program that gets a speedup of about 1.9 >>>>and profits just a bit more than 5% from a filled hashtable. >>>> >>>>That's by definition > 2.0 then. >>> >>>No, that is by hand-waving > 2.0. Because the serial search would >>>_also_ profit by the filled hash table and run faster. >>> >>>Try again... >> >>I already mentionned the reason: the hashtable for the dual cpu >>output is loaded with 2n nodes, the hashtable was loaded for the >>single cpu with n nodes. > >Not in the dts article case. Just read it. the one cpu test was allowed >to ponder longer to prevent just this problem. As I said, I only wanted >to measure exactly how much faster the 16 cpu search was than the one cpu >search. Different levels of hash filling would add another degree of freedom >to the result, and I didn't want that. So I chose an artificial method to >eliminate it. > > > >> >>In case of 16 processors you fill at a 16 times higher speed >>the hashtable than you do single cpu. > >However, if I let the 1 cpu test ponder 16 times as long??? then >what? The hash tables will have about the same "loading"? The >dts article explains that. > > > >> >>You didn't mention a thing about pondering in your article. > > >I certainly did. At least implicitly. In the paragraph where I talked >about the test setup. It says that everything was done the same, so that >every test did about the same work. > >And I _also_ mentioned this to you via email months ago when you asked about >it. I'm sure you can find it. It was one of the emails where I explained >the "test harness program" and how it operated so that I didn't have to sit >there and enter moves after a very long ponder time... > >I can find it and post it unless it was done on ICC one night. But I think it >was email. > >And here it is, remember this??: > >================================================================================ > >===================From hyatt@cis.uab.edu Fri Aug 9 21:45:50 2002 -0500 >Date: Fri, 9 Aug 2002 21:45:49 -0500 (CDT) >From: "Robert M. Hyatt" <hyatt@cis.uab.edu> >X-X-Sender: <hyatt@crafty> >To: Vincent Diepeveen <diep@xs4all.nl> >cc: Gian-Carlo Pascutto <gcp@sjeng.org> >Subject: Re: first position move 9 >In-Reply-To: <3.0.32.20020809174142.00e575d0@pop.xs4all.nl> >Message-ID: <Pine.LNX.4.33.0208092136510.29307-300000@crafty> >MIME-Version: 1.0 >Content-Type: MULTIPART/MIXED; BOUNDARY="445254721-239491367-1028947549=:29307" >Status: O >X-Status: >X-Keywords: >X-UID: 108 > >--445254721-239491367-1028947549=:29307 >Content-Type: TEXT/PLAIN; charset=US-ASCII > > > >OK here is data for the 24 positions vincent sent, fixed so that the >FEN is not broken... > >Notes: > >1. I ran this with the "test" command using hash=96M and hashp=32M, >on the current version of crafty (19.0). > >2. I am enclosing the two log files as attachments. They are pretty >long. log.1cpu and log.4cpu are the attachment names... > >3. I have summarized the results, position by position, giving the >speedup for each. One move in the summary has a *** by it. In that >move, the 4 cpu search produced a different best move than the 1 cpu >test, which happens on occasion. It also changed its mind one extra >time in the last iteration to do this, which hurt the speedup a bit >on it. > >4. I took the last result from each one cpu test, and used that time >for the 1 cpu time. I found the _same_ output in the 4 cpu test and used >that time, even though the 4 cpu test typically goes 1-2 plies deeper >overall.. > >5. The overall speedup was a bit worse than I expected, in that it >was 3.0 overall. But then, I didn't run this test like I did with >the Cray Blitz paper on the JICCA. In that test, I had a driver that >ran Cray Blitz like a console task, and let it ponder normally. It >would "feed it a move" at the right time, based on how long the opponent >took in the real game, scaled to the number of processors being used for >each test. That had good "continuity" between moves as a real game >would normally have. This test didn't clear the hash tables between >moves, but there was no pondering at all to pre-load the hash table >with good information. Also in a real game, when I finish a 12 ply >search, I start the ponder search at 11 plies. In this test, the >search starts at ply 1 each time, unlike the test in the DTS article. >Testing as I did in the DTS paper would help the speedup a bit, based >on plenty of testing when I chose that method for the DTS paper. > >6. I only ran the test one time. 24 positions at 5 minutes per >position takes 2 hours. It needs to be run a dozen times and each >time averaged, but I am not particularly interested in blowing off >that much ICC time. > >7. I hope this stops the nonsense about 1.0 speedups. I didn't get >any. I saw some near 2.0, but not many... These results are pretty >close the the results for the kopec positions and for other tests that >I run from time to time... no big change. I am going to try to re-hash >the "driver" I used for the DTS article as that really is a good >reference for performance during a game. If I can find it, it should >not be too hard to connect it to Crafty since it and CB use the same >console interface commands almost exactly... > > > > > > >Here is the summary: > >pos 1cpu 4cpu S/U > 1 191 69 2.8 > 2 139 71 2.0 > 3 134 47 2.9 > 4 175 58 3.0 > 5 177 49 3.6 > 6 278 104 2.7 > 7 294 93 3.2 > 8 202 86 2.4 > 9 248 99 2.5 >10 153 43 3.6 >11 261 82 3.2 >12 104 30 3.5 >13 148 48 3.1 >14 286 87 3.3 >15 263 117 2.3 >16 158 75 *** 2.1 >17 213 57 3.7 >18 204 85 2.4 >19 125 26 4.8 >20 263 117 2.3 >21 217 76 2.9 >22 202 66 3.1 >23 131 36 3.6 >24 229 64 3.6 > > average speedup: 3.0 > >-- >Robert Hyatt Computer and Information Sciences >hyatt@cis.uab.edu University of Alabama at Birmingham >(205) 934-2213 115A Campbell Hall, UAB Station >(205) 934-5473 FAX Birmingham, AL 35294-1170 >====================================== > > >So don't tell me you didn't know about the pondering in the test. And >that makes the term "slander" even more appropriate. Because you are >making statements you _know_ are false... > > > >> >>I assume you lied again here, otherwise it would have been >>mentionned in 'testing metholodogy'. > >You might need to go _back_ to your dictionary. "slander" is the >word you need to study. > > > > > >> >>You say here it also ran in time of the opponent. I'm missing outputs >>and speedup reports of those positions, you don't even mention in the >>article which move was predicted and what time was spent on it for >>the 16 processor output. > >Correct. I just gave speedup numbers. Correct pondering didn't affect >that at all, because the entire search time was the time I used for all >calculations. As explained... > > > > > >> >>>> >>>>I need to add that you also have to search in the time of the >>>>opponent. >>>> >>>>Easy scenario. Suppose you take 24 positions. 1 position you >>>>get say 1.9 speedup (cleaned hashtable). The other 23 positions >>>>you mispredict the move. However the move is a transposition to >>>>the search tree the program plays. >>>> >>>>Then the moves get played and you start a new search with that hashtable. >>>> >>>>So you get like > 10 ply out of hashtable directly. >>> >>>So? So does the one-processor test and it all recalibrates nicely... >>> >>> >>>> >>>>That saves n minutes calculation where you calculate n minutes 50% of >>>>your search is for free then. I don't need to mention speedup is >>>>about 2x 1.9 = 3.8 then at 2 processors when compared to someone using >>>>a cleaned hashtable each time getting a 1.9 speedup. >>> >>>Nobody does that. My speedups are calculated consistently, unlike the >>>mish-mash crap you do above. If the one processor test uses exactly the >>>same approach as the 4 processor test, then the four processor test doesn't >>>get any "gain" from hashing that the one processor test doesn't also get... >>> >>>Stop waving your hands. You look absolutely ridiculous. >>> >>> >>> >>>> >>>>The average speedup is then : (23 * 3.8) + 1.9 = 3.72 >>>>this at 2 processors. >>> >>> >>>If I compare the speed of a two processor search to the speed at which >>>a stump-grinder can grind stumps, I get a speedup of > 1,000,000. Not >>>that the comparison makes much sense. But it makes as much sense as your >>>rambling above...
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.