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