Author: Robert Hyatt
Date: 21:07:18 07/21/00
Go up one level in this thread
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. It is very hard to come up with some sort of 'equalizer' formula. Even if I had the machine in my office to compare with Crafty, I think the formula would have a very large error term when fitting their nodes to my nodes or vice- versa. But their 15 seconds certainly fits within reasonable bounds, knowing the speed of the hardware could be searching anywhere between 3000M nodes to 15000M nodes in that time frame, depending on the duty cycle the processors were running at, and the search efficiency the software was getting with the parallel search. They weren't changing their mind much during that search, which suggests a pretty good move ordering and efficiency level. My program flipped and flopped a couple of times which killed my node count and ran it way up. Lots of things would/could make this comparison easier or harder...
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.