Author: Vincent Diepeveen
Date: 11:02:54 09/04/02
Go up one level in this thread
On September 04, 2002 at 12:43:37, Robert Hyatt wrote: Please run crafty at 16 processors. Fine with me. Even though it's a different program. I have no problems with it. But rewrite also the article then that it's not a DTS thing, but a smp_lock thing that doesn't scale above 8 cpu's. >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.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.