Author: blass uri
Date: 21:24:39 07/21/00
Go up one level in this thread
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
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.