Author: Robert Hyatt
Date: 07:59:56 08/22/02
Go up one level in this thread
On August 22, 2002 at 06:47:34, Gian-Carlo Pascutto wrote: >Some excerpts from the logfiles: > > 7(5) #[e6](6)############################## 6 T=2 >Pe7e6 bc1b2 Nb8d7 ph2h3 Bg4f5 > 8(6) #[e6](9)############################## 9 T=6 >Pe7e6 nf3e5 Ng8h6 bc1b2 Bg4e2p bf1e2B > > 7(5) #[e5](21)####################################### 21 T=2 >Pe6e5 pe3e4 Ph7h6 pg3g4 > 8(6) #[e5](13)####################################### 13 T=5 >Pe6e5 pe3e4 Ph7h6 qd1e2 Rf8e8 pa2a4 > > >7(4)#[Rfe8](-12)#############################[b5](-11)#[Qb6](13)################## >13 T=3 >Qa5b6 pe3e4 Bh5f3n nd2f3B Qb6f2p rf1f2Q Bd6g3p bb2f6N > 8(6) #[Qb6](-17)[Qb6](-17) -17v T=3 >Qa5b6 pe3e4 Bh5f3n nd2f3B Qb6f2p rf1f2Q Bd6g3p bb2f6N > 8(6) >#[Qb6](-18)###############[Bxf3](-8)#############[e5](-6)#################[Rae8](-5) >-5 T=11 >Ra8e8 pc2c4 Pe6e5 pd3d4 Pb7b6 pb3b4 Qa5a4 > > 7(5) #[Qc5](0)############################################## 0 T=2 >Qa5c5 pg3g4 Bh5g6 nh4g6B Pf7g6n > 8(6) #[Qc5](-30)[Qc5](-30) -30v T=3 >Qa5c5 pg3g4 Bh5g6 nh4g6B Pf7g6n qe1d1 Pe6e5 > >If you claim that Deep Blue's nominal depth is the sum of the two numbers, >then in all of these cases it is bumping up it's nominal search depth by 2 ply, >which makes little sense. > >i.e. it's going from 12 to 14 ply. > >And in all cases, there is no explosion in search time for this '2 ply jump'. If you understand their hardware, then this isn't a surprise. In summary: The SP2 has to produce positions that get handed off to the chess processors. If the SP2 produces positions, one every N units of time, then the chess processors have to be able to search them in N units of time to be 100% balanced. This is impossible. Therefore, as the search advances, the hardware depth generally has to change as well, otherwise either the SP2 gets ahead of the processors and the SP2 ends up waiting, or it can't keep up and the processors sit idle. That is the reason they have the variable hardware depth. And it is the reason why they could not search at 1B nodes per second for any period of time. The best they could do is 100% chess processor utilization on those rare occasions where the software search just barely keeps up with supplying positions to the hardware. The rest of the time the software search is waiting on the hardware processors. Hsu claimed in his dissertation that a "good search" would produce 70% duty-cycle for the chess processors. Next, note that there is no way to search a half-ply. So if you advance by 1, what happens? Does the software search do that? If so, it slows down and the hardware can't be kept busy. Does the hardware get that extra ply? If so, it slows down and the software search has to wait. Balance is the problem... Hsu's thesis is must-reading if you want to talk about their search and understand the unique problems it had to overcome that we don't think about in a general-purpose implementation... > >That does not make sense - it only does when you take the first number as >the nominal ply depth and the second number as the part of that that was >done by the hardware searches. > >-- >GCP
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.