Author: Robert Hyatt
Date: 06:48:08 07/22/00
Go up one level in this thread
On July 22, 2000 at 03:04:34, blass uri wrote: >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 You have to read what I wrote carefully and think about it a while. All I said was that the last 1/3 of their search does fewer extensions than the first 2/3 of their search does. In crafty, that last 1/3 limit doesn't happen. It doesn't mean that they do less. That is hard to judge. It also doesn't mean they do more. Singular extensions are different than check extensions and the like, as they tend to be more germane to the position. A check extension can be futile. But an extension in a position where there is only one good move can be very important. My point is that it is very hard to compare the two programs overall. I watched deep thought for several years. I found it very hard to try to look at my search (in Cray Blitz) and predict how deep they would go on the same position. The data was all over the place. In the same position, they would sometimes go deeper, shallower, and occasionally the same. The only conclusion for that is that in the same position, sometimes they extend way more, sometimes way less, and sometimes close to the same amount. I did ask, point blank, if they decided to use null-move or any other sort of forward pruning/selective search in DB2. The answer was a flat no. The only real time-saver they added in DB2 was futility pruning in the q-search, which they never did prior to that. However they were _emphatic_ about the lack of any forward-pruning stuff (null move, etc). I'm not sure what comparing nodes will do. I ran a few tests with null move turned off last night, and in some odd positions, no null move is actually faster. It is going to be very hard to compare anything with them without having access to their machine...
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.