Author: Robert Hyatt
Date: 19:14:05 02/02/02
Go up one level in this thread
On February 02, 2002 at 12:34:06, Uri Blass wrote: >On February 02, 2002 at 12:01:53, Robert Hyatt wrote: > >>On February 01, 2002 at 13:33:51, Ed Schröder wrote: >> >>>On February 01, 2002 at 09:05:35, Robert Hyatt wrote: >>> >>>>OK Here is the email again: >>>> >>>>My first question to them was "did the X(Y) depth notation in Deep Thought >>>>mean X plies in software, Y additional plies in hardware as it did when I >>>>watched your program?" Here is a reply from a member of the team: >>>> >>>>Quote On--------------------------------------------------------------------- >>>> >>>>In the DT logs, the number in () after the plies is indeed >>>>the depth of the HW. It was changed dynamically, but only >>>>within a narror range (3, 4, somethimes 5). I would not >>>>be surprise if CB kept this notation, but I don't know for >>>>sure. >>>> >>>>As you say, too >>>>low, and the HW ends up idle because the host is too slow. >>>>Too high, and the host is bored... >>>>However the real reason for not letting the HW go too deep >>>>is search efficiency: the HW does not use the transposition >>>>table, hence it was best to balance the memory bandwidth >>>>availabe on the host for hash table accesses. >>>> >>>>Quote Off-------------------------------------------------------------------- >>>> >>>>The second quote came as a response to my question "Does DB report the >>>>depth using the same form of the X(Y) notation as was used in Deep Thought?" >>>>Here is the answer, again: >>>> >>>> >>>>Quote On--------------------------------------------------------------------- >>>> >>>>Hi, >>>> >>>>CB is in town this week and I had lunch with him, where we >>>>chatted a bit about DB and the like. A while back, when you >>>>looked over DB's logs (put up by Murray without IBM careing >>>>much), you were impressed by their depth and branching factor. >>>> >>>>Well, the depth notation is as I told you and just like it was >>>>in DT, so it really does go *that* deep... >>>> >>>>For example, in DT, 9(4) meant a 13 ply search. >>>> >>>>Quote Off-------------------------------------------------------------------- >>> >>> >>>The last sentence is very convincing. >>> >>> >>>>That is the best I can do. I asked about DT, which I saw _many_ times from >>>>behind their monitor and they explained the X(Y) notation as I have reported, >>>>several times. I then asked if DB kept the same notation and CB (nickname for >>>>Hsu) said "yes it did." >>>> >>>>Can it be any more clear than that? >>> >>>No it can not, according DB team 12(6) = 18. >>> >>>However the statement conflicts with their own documentation, hence the >>>confusion. >>> >>>So maybe I am wrong about the subject. >>> >>>Ed >> >> >>As I mentioned in the past, on more than one occasion they had said "we did >>an N ply search there" and when I saw their output it said N(X). I didn't give >>it any thought until I finally asked "what is that X value?". And Murray or >>Hsu explained it. I then asked "why did you say N ply?" and one of them >>responded "the hardware search is much simpler than the real software search >>and we tend to think of that as a unique form of a 'static evaluation' even >>though it does include a search + capture search." > >I guess that the reason is simply that it was basically selective search that is >clearly more selective than the search that other programs are doing when they >search X plies. > >This search can include moves that are not captures but I guess that it includes >only part of them and is more selective than normal null move pruning. > >I see no reason for them to say N(X) and not N+X(X) if it is not the case. > >12 plies brute force+6 plies selective search in the way that Crafty or Rebel or >another top program of today do seem to be impossible even when I know that >12(6) was only in part of the cases. > >Top programs often need about 100Knodes for searching 6 plies when it seems that >the hardware of deeper blue needed only 8 Knodes when the hardware could not use >hash tables if I understand correctly. > >Uri Remember that Hsu didn't even _count_ nodes. The hardware wasn't capable of doing so (Belle didn't count nodes either, for reference). Hsu's only concern was that each chess processor searched at between 2 and 2.4 million nodes per second. For a given depth, in a given position, there was a specific D the hardware could search to in a given time. And since the SP2 was doing the first 2/3 of the search, it could produce positions at a specific frequency or rate. If it produced them too quickly, either the hardware search depth had to be toned back, or the SP2 would have to wait on the hardware processors which slowed things down. If the depth was too shallow (on the hardware) the processors could do the searches faster than the SP2 could provide positions and again, things ran too slow. Hsu's only concern was balancing the search depth on the chess processors with the speed of the parallel search on the SP2 mainframe. As a result, he simply reported how many plies down the tree the software tried to search (not counting extensions) and how many plies the hardware searched in order to keep up optimally... I doubt he ever gave much thought to the size of the trees or the great discussions that would occur as a result of the raw depth numbers...
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.