Author: Vincent Diepeveen
Date: 20:42:57 09/03/02
Go up one level in this thread
On September 03, 2002 at 22:19:06, Robert Hyatt wrote: the word 'time' is the crucial thing bob everywhere. in fact in crafty you don't even mention how many nodes it needs each ply. you just post how much time a ply it needs. sometimes it's not even clear whether it finished or started a plydepth for the outside, just the time is always very clear mentionned. We talk about time. if you have the times, you can calculate the speedups. nothing more and nothing less. if you have a speedup and consider time to get that speedup a detail, then the speedup numbers are not true. If the times are not correct therefore nothing can be correct. If the times are there to hide the speedup of 16 cpu's was not as great as 1-8 cpu's, then it is obvious not a fair thing to do. The times bob. Not a round off scenario can save you. Not an 'excel rounded my times to whole numbers' scenario can save you. Do these times look like 'rounded off times' to you? Sure not to me: First, times in seconds: pos 1 2 4 8 16 1 2,830 1,415 832 435 311 2 2,849 1,424 791 438 274 3 3,274 1,637 884 467 239 4 2,308 1,154 591 349 208 5 1,584 792 440 243 178 6 4,294 2,147 1,160 670 452 7 1,888 993 524 273 187 8 7,275 3,637 1,966 1,039 680 9 3,940 1,970 1,094 635 398 10 2,431 1,215 639 333 187 11 3,062 1,531 827 425 247 12 2,518 1,325 662 364 219 13 2,131 1,121 560 313 192 14 1,871 935 534 296 191 15 2,648 1,324 715 378 243 16 2,347 1,235 601 321 182 17 4,884 2,872 1,878 1,085 814 18 646 358 222 124 84 19 2,983 1,491 785 426 226 20 7,473 3,736 1,916 1,083 530 21 3,626 1,813 906 489 237 22 2,560 1,347 691 412 264 23 2,039 1,019 536 323 206 24 2,563 1,281 657 337 178 But if horrors are not enough. He there are MORE statistical ways to review results. amazingly, but true. anyway. it is bedtime here. tomorrow another output hopefully if the excel experts are awake. >On September 03, 2002 at 20:15:04, Vincent Diepeveen wrote: > >>On September 03, 2002 at 20:00:56, Vincent Diepeveen wrote: >> >>here a small part of what we discussed during our 3 >>hour conversation at 20 august 2002 at icc: > > >Nothing in that contradicts a single thing I have said. Notice that you >were harping on the _speedup_ data to myself and Marcel. I had no idea >you were talking about something other than that, or this entire fiasco >could have been avoided. > >If you learn to first ask, and _then_ do a public lynching, you can avoid >_lots_ of problems... In fact, if you could learn how to look _before_ >leaping, you would be a _much_ better person. > >Of course, if you are in the mode of "prove my point at all costs" then >you can "pay your money and take your chances". You aren't going to beat >a full crossbar machine with a NUMA machine. anybody will tell you that. > > > > >> >>. if i can show that there is a chance that something has a chance of 1 - 1 / >>10^30 to happen, then that's accepted even by law to be how something happened >>(told Hyatt) >>. not to mention in science >>(told Hyatt) >>diep(C) tells you: diep's not doing very well vs. crafty >>tell diep it's repeating games >>(told diep, who is playing) >>. what is in diep.ini >>(told diep, who is playing) >>. tournament false ? >>(told diep, who is playing) >>Hyatt tells you: ok... what does that have to do with DTS paper??? >>. hopefully >>(told diep, who is playing) >>diep(C) tells you: let me check >>tell hyatt it's not so hard to show that the numbers are not the numbers you had >>at your output >>(told Hyatt) >>diep(C) tells you: yikes it's on true >>diep(C) tells you: fixed just now >>. with a chance of 0.999999999999999999999999999999999999999 >>(told Hyatt) >>Hyatt tells you: I have no idea what you mean... they came _directly_ from the >>logs... >>. about 30 nines >>(told Hyatt) >>. 30 nines bob >>(told Hyatt) >>. not 1 >>(told Hyatt) >>Hyatt tells you: that is _meaningless_... >>Hyatt tells you: I _know_ where the data came from... >>diep(C) tells you: is this endgame lost?! >>. me too >>(told Hyatt) >>. and it wasn't from the logs >>(told Hyatt) >>Hyatt tells you: it was very close to the data that was presented in my >>dissertation... >>. with exception of the 16 processor run >>(told Hyatt) >>Hyatt tells you: it _absolutely_ was from the logs... >>Hyatt tells you: and I'm sorry to say I have _no_ idea what you are talking >>about here... >>Hyatt tells you: IE I did _exactly_ the same thing in the DTS paper that I did >>in the test I ran for you the other day with 1 and 4 procssors... >>Hyatt tells you: Just grabbed matching times and computed the speedup... >>. i'm not talking about crafty here bob >>(told Hyatt) >>Hyatt tells you: I am talking about _both_... >>. but about the DTS numbers presented in march 1997 >>(told Hyatt) >>. page 16 issue 1 1997 >>(told Hyatt) >>. table 3 >>(told Hyatt) >>Hyatt tells you: they were obtained the same way... >>Hyatt tells you: brb.. son on phone... wants to ask me something.. >>. my question is simply what you prefer i go for in a publication >>(told Hyatt) >>diep(C) tells you: diep could be in trouble because of no egtb >>. take your time to answer bob >>(told Hyatt, who has been idle for 2 minutes) >>date >>Tue Aug 13 22:18:37 EDT (New York time) >>diep(C) tells you: ? >>Hyatt tells you: totally up to you... if you want to claim I faked the data, >>feel free. I won't have a lot of trouble proving I didn't. I'm sure I can find >>a C90 to run a few positions on for a witness... >>diep(C) tells you: kc4-b5-a6 >>diep(C) tells you: then pawns run >>diep(C) tells you: right? >>tell hyatt the easy alternative is to blame nullmove and the bigger search >>depths >>(told Hyatt, who has been idle for 3 minutes) >>. you got like 11 ply or so at 16 processors at the time? >>(told Hyatt, who has been idle for 3 minutes) >>. i start at 11 ply of course single cpu already >>(told Hyatt, who has been idle for 4 minutes) >>diep(C) tells you: now i think it's a draw >>tell diep moment important discussion here >>(told diep, who is playing) >>Hyatt tells you: I don't believe _either_ approach will work... you either have >>to claim null-move is the problem, where _anybody_ with Crafty can show that it >>is a minor issue... or you have to claim that data was faked which is also >>simple to disprove... >>tell hyatt as proven so far it's 0.2 different in speedup at 4 processors >>already >>(told Hyatt) >>. that's a lot >>(told Hyatt) >>. diep it's bigger >>(told Hyatt) >>Hyatt tells you: problem is, we tried crafty with _no_ null move, we should have >>tried it with R=1... >>Hyatt tells you: as that was what CB used... >>diep(C) tells you: umm Bg5? >>diep(C) tells you: why not bc7 >>Hyatt tells you: I suspect the difference between R=1 and R=2 is even smaller >>than .1 with 4 processors... >>. CB had non recursive nullmove right? >>(told Hyatt) >>diep(C) tells you: and shuffle >>. saving up to 25-75% nodes that R=1 thing didn't it? >>(told Hyatt) >>Hyatt tells you: yes >>. nullmove for diep saves about factor 100 >>(told Hyatt) >>. 4 ply >>(told Hyatt) >>. 10000% >>(told Hyatt) >>Hyatt tells you: not for crafty... about 2 plies for me generally... >>Hyatt tells you: maybe 2-3 with R=3 >>. at tournament time sure. now i go produce outputs with a lot of processors >>(told Hyatt) >>. so single cpu that'll be like thirty times 3 minutes = 90 minutes >>(told Hyatt) >>Hyatt tells you: that was the hard part of the DTS article... running positions >>for 1 hour is not easy on a machine that might not stay up that long... >>. i have no such problems >>(told Hyatt) >>. machine has 1024 processors >>(told Hyatt) >>. 1 terabyte/s bandwidth >>(told Hyatt) >>. plenty of processors to use a few for testing >>(told Hyatt) >>Hyatt tells you: I did... my machine was a software development machine as well >>as a production machine. To run that game at one cpu took over one day of cpu >>time... which meant 2-3 days of non-interrupted running... that was _hard_ to >>get... >>Hyatt tells you: they rebooted at night to test different O/S patches, and that >>would kill my test as the engire game had to be played in one session... >>. this machine idles a lot. we both know why. >>(told Hyatt) >>. and after 5 PM when scientists go home i can test on this testpartition easily >>(told Hyatt) >>. like i do now >>(told Hyatt) >>diep(C) tells you: = >>ob diep >>You are now observing game 502. >>tell diep yes = >>(told diep, who is playing) >> >> >>>On September 03, 2002 at 19:54:41, Robert Hyatt wrote: >>> >>>How can you calculate speedup based upon node counts >>>instead of time? >>> >>>Where is the accurate time table if your latest statement now >>>is that the time table in journal of icca is not correct? >>> >>>You seem to have you roriginal text of your paper still at home, >>>so you must have the logfiles still too? >>> >>>Best regards, >>>Vincent >>> >>>>On September 03, 2002 at 18:22:04, Dave Gomboc wrote: >>>> >>>>>On September 03, 2002 at 18:03:14, Gian-Carlo Pascutto wrote: >>>>> >>>>>>However reasonable your explanations may be, the gist of your DTS article >>>>>>and the most important thing for comparison were the speedup numbers. After >>>>>>what we discovered and what you just posted, it is clear that they are >>>>>>based on very shaky foundations. >>>>>> >>>>>>What's far worse, until you were directly accused, there was no indication >>>>>>whatsoever for all the fiddling that was done with the auxiliary data. When >>>>>>you were accused, you denied again, until other people supported Vincent's >>>>>>point of view, when you suddenly got an email from an unknown person you're >>>>>>not willing to disclose that 'refreshed your memory'. >>>>>> >>>>>>Additionally, the only other thing to support DTS, you PhD thesis, appears >>>>>>to be basically totally unfindable for third parties. >>>>>> >>>>>>I hope you realize that a request from you to trust your numbers isn't >>>>>>very convincing. In fact, with what we know now, I'm pretty sure the >>>>>>article would never have gotten published in the first place. >>>>>> >>>>>>If Vincent wanted to discredit your results, then as far as I'm concerned, >>>>>>he's succeeded 100%. >>>>>> >>>>>>-- >>>>>>GCP >>>>> >>>>> >>>>>I don't agree: the main result is the speedup, which was directly measured -- >>>>>though I'm certainly not a fan of the estimated node counts being there (at >>>>>least without something saying "estimated", which the article may or may not >>>>>have done). >>>> >>>>In this case, Vincent's "your bad memory" would actually be right. >>>> >>>>The only thing that would have been better would be had he simply asked me >>>>specifically what he stated in his first post here. He mentioned a week ago >>>>that he thought my data was "faked". I had no idea what he was talking about >>>>and I told him _exactly_ what we had done for the speedup stuff.. How I ran >>>>the tests, taking pondering into account, etc. Never for a minute thought >>>>he was talking about the nodes or times, because he kept talking about the >>>>11.1 is fake... >>>> >>>>He was right and wrong. The 11.1 was _not_ a faked result. But the node >>>>counts were definitely calculated because that was the only way I could think >>>>of to come up with them. >>>> >>>> >>>> >>>>> >>>>>But in the main, the least reliable source for information at CCC is Vincent -- >>>>>indeed, I'd go so far as to say that whenever he claims something, I tend to >>>>>believe that the opposite is true, unless there are some other, more credible >>>>>people who agree with him. >>>>> >>>>>Dave
This page took 0.01 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.