Author: Ernst A. Heinz
Date: 09:18:17 01/26/00
Go up one level in this thread
On January 25, 2000 at 23:38:06, Peter W. Gillgasch wrote: > >On January 25, 2000 at 22:27:40, Ernst A. Heinz wrote: > >>I exactly understand what you mean but I am not so sure >>about your conclusions. >> >> 1. The static evaluation hardware has "fast" and "slow" >> parts which differ considerably in execution cycles. >> The "slow" part is guarded by a futility-style lazy >> mechanism which leads to differences in execution time >> per node. >> >> 2. The shape of the search tree itself leads to differences >> in execution time per node because the number of moves >> followed before you get a cutoff varies. >> >>(1) + (2) ==> search speed as measured in nodes per second >> may differ significantly in some positions even >> for chess hardware such as Deep Blue! > >I have thought about both issues before posting. I did not doubt that -- but you obviously have not yet read Hsu's article in IEEE Micro, March/April 1999 (see below). >Ad 1: This was true for Deep Thought since the difference > between the fast and the slow eval was noticeable > due to the sequential properties introduced by > the Xylinx devices looking at the position on a > file by file basis. Since DBII is not hampered > by issues like FPGA capacities this is the first > bottleneck that was to be removed. As Dave Footland > has reported they had interesting things in their > evaluation. In the light of this and in the light > of things Hans has said it it extremely unlikely > that they ever take a "slow eval" in DB since there > is (a) probably no speed gain in doing so and (b) > things like pins and king safety can add up quite > a bit, taking a "slow eval" makes no sense in a > machine which knows that the queen is pinned and > will be lost versus a bishop or that there is a > mate in one versus your king. > > Of course, we do not have proof if FHH still did > that "slow eval" design error in DB. Sorry for raining onto your parade -- but we do have proof if we believe in Hsu's writings! Before continuing the argument, I like to send you back to the reading room: on page 75 of his article about the DB chess chips in IEEE Micro, March/April 1999, Hsu presents an abstract flow-chart for the basic search algorithm of the chips. This includes a "fast" part of the static evaluation and a futility-guarded "slow" part. Obviously, Hsu still liked your alleged "design error" which might have proven better than Berliner and you seem to think. As usual, Hsu did not care much about Berliner's claims which were quite often not backed up by conclusive and/or reproducible experimental data. =Ernst=
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.