Author: blass uri
Date: 00:04:34 07/22/00
Go up one level in this thread
On July 22, 2000 at 00:41:13, Robert Hyatt wrote: >On July 22, 2000 at 00:24:39, blass uri wrote: > >>On July 22, 2000 at 00:07:18, Robert Hyatt wrote: >> >>>On July 21, 2000 at 23:36:51, blass uri wrote: >>> >>>>On July 21, 2000 at 23:27:47, Robert Hyatt wrote: >>>> >>>><snipped> >>>>>Here is my numbers, on a quad xeon/550mhz machine. >>>>> >>>>>9 plies took 2M nodes >>>>>10 plies took 5M nodes (this is 5M total from plies 1-10) >>>>>11 plies took 9M nodes >>>>>12 plies took 100M nodes >>>>>13 plies took 500M nodes >>>>>14 plies took 700M nodes >>>>>15 plies took 1300M nodes >>>>> >>>>>If I could average 200M nodes per second, I could do that search in probably >>>>>under 5 seconds, given enough memory. If I could peak at 1B, I could do that >>>>>search between 1 and 5 seconds somewhere, depending on how the peak went... >>>>> >>>>>Note that his 30% efficiency figure is an average as is my 3.2X faster on a >>>>>quad. I have many positions where I run 4x faster. I have a couple where >>>>>I run 1/10th as fast as one cpu... >>>>> >>>>>For me, these numbers should be reduced by at least 25%, which is my search >>>>>overhead (extra nodes searched that a sequential search would not examine). >>>>>Hsu's 200M figure already had his overhead factored out... >>>>> >>>>>I am not sure what this proves, when you factor in parallel search. Odd >>>>>things happen. Some searches go way fast. Others go way slow. Trying to >>>>>compare searches by comparing depths is not so useful. In some positions >>>>>I might extend way too much. In other positions they might do the same. >>>>>In other positions we might extend pretty equally. How to know and compare? >>>>> >>>>>I could probably search this tree in less than 1/2 the nodes if I had a decent >>>>>sized hash table. This grossly overruns anything I can use on this machine >>>>>tonight... >>>> >>>>Did you use recursive null move pruning in this search?(I think you should not >>>>use null move pruning in order to do the right comparison) >>>> >>>>Uri >>> >>> >>>I ran "crafty". I can turn null off. or anything else. But it still doesn't >>>give us an accurate comparison. Remember that DB has two parts to the search. >>> >>>The first number is the software search, which does _all_ their extension stuff >>>including singular extensions and whatever. The second number is their hardware >>>search which doesn't do singular extensions. I am pretty sure the hardware does >>>"out of check" extensions as Belle did and the hardware was patterned after the >>>Belle machine. Belle didn't do recapture extensions, so I don't know whether >>>the DB chip does or not. The DB hardware does do futility pruning in the q- >>>search while not everybody does that (I do). So comparing their 9+6 time to >>>my 15 time is probably not right. There 9+6 is probably closer to my 13/14 >>>when you factor in the fact that I can trigger extensions anywhere from ply 1 >>>to ply N, while for them, the last 6 plies trigger fewer extensions in the >>>hardware. >> >>I understood that you claim that they do more extensions than other programs and >>not less extensions(if they cannot trigger extensions in the last 6 plies >>then the picture may be different and I may be right that they played c4 against >>Fritz3 because of lack of extensions). >> >>Uri > >Note that I didn't say "no extensions" in the last 6 plies. I said "no singular >extensions in the last 6 plies". Crafty also does not do singular extensions and you said that their 15 plies are close to your 13-14 plies that means that Crafty does more extensions than Deeper blue inspite of not doing singular extension. Uri
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.