Re: [computer-go] question regarding Hydra Chess Supercomputer

[Don Dailey <drd@xxxxxxx>]

I agree  with you, but  according to Bob  Deep-Blue had none  of these
issues, he  claimed there were  *no* compromises, that even  given the
same numer of nodes Deep Blue would blow everything else away.

My feeling was that the top  PC programs would probably beat Deep Blue
if you waited for a computer fast  enough to be able to MATCH the same
number  of nodes per  second.  I  made a  statement something  to that
effect which started the discussion (ok,  argument.)

I eventually  shut up  for 2  reasons.  Bob could  yell louder  than I
could but the  other reason was that I was starting  to come across as
anti-Deep Blue even  though I wasn't.  When you  end up in discussions
like this  people try to push you  into a box.  In  this case, several
were into  Deep Blue  hero worship  and I was  too, but  evidently not
enough so I got placed into the anit-blue box and I couldn't get out.

- Don





   From: "chrilly" <chrilly@xxxxxxxxxxxxxxxxx>
   Date: Mon, 25 Oct 2004 01:06:41 +0100
   X-Priority: 3
   X-MSMail-Priority: Normal
   X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
   X-AntiSpam: Checked for restricted content by Gordano's AntiSpam Software
   X-Scanned-By: MIMEDefang 2.42

   >
   >You say  hardware search  is less efficient  than software  search.
   >
   It is much more difficult to implement. Implementing a recursive function
   with a Finite-State-Matchine is not easy. Especially getting all the timing
   right. A lot of things run in parallel, some operations take 1, some 2 some
   3 cycles. The Hydra FSM is simply a nightmare.
   The Deep-Blue Hardware search was particulary simple. E.g. They had not even
   a killer-heuristic (Hydra has). Such things like History-Heuristic can
   principially not be implemented (at least in the Deep-Blue and Hydra
   design). Has to do with move-masking.
   Additionally there is no reasonable way to implement a hashtabelle. Even if
   one has RAM on the FPGA-cards, one can not distribute the hashtables in a
   massivly parallel system.
   DB had also not null-move. Hydra has.
   Additionally the software part of the search gets only a few bits of
   information from the hardware part. In Hydra its 32-Bits.If everything is in
   software, one can use the full information of this search also for the other
   parts of the tree.

   This points can all be solved, but not within the Deep-Blue and Hydra
   architecture. Besides using FPGA Hydra is from the architecture quite
   similar to DB.

   > computer chess  group and got heavily criticized  by Bob Hyatt who
   >defended Deep Blue on this issue.
   >
   There is no need to defend DB on the search-issue. Feng Hsu openly discussed
   this problems in his publications and never claimed that his search is more
   effective than the best software-searches. He only claimed that his method
   is more effective than that of the other hardware-engines Hitech and of
   Belle. I claim that the Hydra search is better than the DB-one.
   >
   >I couldn't figure how the  hash table implementation would be as good,
   >
   There are no hashtables in the hardware part of DB.
   >
   >or  how the  evaluation  could be  as  good because  it's  so easy  to
   >engineer software code  than hardware code.
   >
   The evaluation is a different story. I think one can make a better
   evaluation in hardware than in software. Especially in the
   middle-game the Hydra evaluation is even now better than the eval of Fritz
   or
   Shredder. In the endgame the software programms have still an edge..
   There is no speed-knowledge tradeoff. Additional knowledge needs more logic,
   is cumbersome to implement,  but there is only little slowdown. Everything
   can be made in parallel. The main part of the Hydra-Evaluation is a
   super-move-generator. This move-generator generates for both sides the
   attack information and a quite accurate evaluation of attacks/defenses plus
   pins is done. This is in software very expensive, in Hardware it takes 3
   cycels. What is hard to implement are e.g. some special cases in the
   endgame.
   The main problem is in hardware, that the evaluation is so cheap. One has a
   lot of terms and tuning is very complicated/work intensive. Also the
   turnaround times for a new version is even in FPGAs much longer than in
   software.
   >
   >Bob was  so strong in  his opinion  that I just  had to shut  up.
   >
   Sounds familar.

   Chrilly



_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/