Author: Vincent Diepeveen
Date: 10:32:30 09/04/02
Go up one level in this thread
On September 04, 2002 at 12:43:37, Robert Hyatt wrote: you say you was very busy getting crafty to optimize it for alpha that year. The article was published in march 1997, the world championship in october 1997, so i assume you refer to 'that year' but the year before 1996 in Jakarta? How can a program that is completely different from crafty and running at a different architecture need time from you instead of SYSTEM time? You tested different versions for the article and had to modify cray blitz each time or something? What work did cray blitz need? >On September 04, 2002 at 10:39:10, Vincent Diepeveen wrote: > >>On September 04, 2002 at 00:32:05, Robert Hyatt wrote: >> >>>On September 03, 2002 at 23:42:57, Vincent Diepeveen wrote: >>> >>>>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. >>> >>>Certainly... >>> >>> >>>> >>>>We talk about time. if you have the times, you can calculate the >>>>speedups. nothing more and nothing less. >>> >>>Never said otherwise. I specifically said that the speedups were calculated >>>_from_ the times mined from the log files for the 5 tests... >> >>Do you by this officially claim now that the table with >>the search times and node numbers is a fake table which >>you calculated later yourself based upon speedups which >>you had written down on a small noteblock? > > >Nope. The speedup table was produced by a "log eater". I have a printout >of the simple speedup table it produced, but as you might suspect, it is >_exactly_ the data in the dts paper as that is where it came from. > >When we were asked for nodes, I had only one way to produce them. Previous >tests by everyone were always conducted to a fixed depth, which means that >the last iteration was always finished. There, the node counts were easy to >derive. but in this test, the "benchmark game" was not done like that. Often >we got a PV out, then the search ran a couple minutes more and stopped without >finishing the iteration. I had the node count, but what part of those nodes >were searched up to the point that the pv was displayed, and what part was >searched after that and therefore useless? Impossible to directly say. So >we calculated them, because the program carefully kept up with how much CPU >time was used by each CPU doing real searching, rather than spinning waiting >on work, the same was as the cpu% in Crafty does this today. But since we >knew the total number of nodes searched, the total time taken to search those >nodes, and the total time taken to produce "the PV we were interested in" we >could certainly compute what part of the nodes could be attributed to producing >that PV plus all the previous iterations. So the nodes are based on the >speedups as the easiest way to produce them... what more can I say? > >As far as the time data, I simply do not remember. We might have had to >extrapolate that due to the data loss I mentioned. We might have chosen to >extrapolate it at the same time we were extrapolating nodes. I won't make >a difinitive statement since I don't remember. I remember being very busy >trying to get ready for a chess tournament that year and trying to get >Crafty optimized for an alpha we were using... > > > > > >> >>So the tables 3 and 4 on page 16 at icca issue 1 1997 >>are completely *faked* you claim now? >> > > >Nope. There is a _huge_ difference between "faked" and "extrapolated". > >Should I run a few positions with Crafty, and post real nodes and times and >speedups, and then extrapolate nodes and times from the speedup, so that we >can see how much inaccuracy there is in the process? > >Or do you really not want to see that because you know what it will show??? > > > > >>>> >>>>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. >>> >>> >>> >>>I have no idea what you mean. The speedups _were_ directly calculated from >>>the times in the log files. That table was put into the paper. Nodes and >>>times were added much later. Perhaps 2-3 years even. Remember that the game >>>was played late in 1993 in Indianapolis. I ran the 1-2-4-8 tests during the >>>next year. So it was essentially finished in 1994. It was published several >>>years later after significant revisions to shorten it, and a few additions to >>>add more data. >> >>>That's all that happened. The speedups _were_ the critical data that were >>>calculated directly from log times. I've said it several times. You don't >>>listen... >> >> >> >>>> >>>>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: >>> >>>I haven't said a thing about rounding times. Someone asked about rounding >>>off the speedups which certainly happened since they are only given to one >>>decimel place... >>> >>>But no one has suggested _anything_ about rounding the times. As I said, >>>it is possible that when we computed the node counts, we computed the time, >>>since the speedups were computed from the raw times, the raw times can be >>>reconstructed with very little error from the speedups... >>> >>> >>>> >>>> >>>>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. >>>> >>> >>>I can hardly wait. If you spent as much time working on improving your stuff >>>as you do trying to discredit everyone else, you'd be far better off... >>> >>>But follow the path you think does you the best service...
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.