Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Quiescence search - checking & check evasion moves and Hsu

Author: Will Singleton

Date: 16:27:00 04/10/02

Go up one level in this thread


On April 10, 2002 at 16:38:49, Gian-Carlo Pascutto wrote:

>On April 10, 2002 at 00:27:54, Keith Evans wrote:
>
>>When Hsu designed the move generator for Deep Blue he added extra hardware so
>>that he could generate checking (even discovered checks) and check evasion moves
>>more quickly than his first move generator could. (Compare the diagrams for the
>>square transmitters and receivers in the IEEE micro article to those in his
>>thesis and to those describing the Belle generator.) He could have generated
>>these moves without the extra hardware and design time by iterating through
>>moves and throwing away moves which didn't meet the criteria, but apparently he
>>thought that the performance of the move generator was important enough in these
>>cases to justify adding the complexity.
>>
>>What's the general opinion on this? Was this time well spent, or was it a waste
>>of time? I searched for information on what programs typically do during qsearch
>>and couldn't find much of anything directly related. It seems like he would have
>>simulated this before commiting to design, and perhaps discussed it publicly
>>with some top programmers.
>
>In the qsearch, being able to generate only capture moves fast is
>a nice speed advantage. If you want to do checks/check evasions too,
>you'll have to generate these moves somehow. If you have to fall
>back to your standard movegen, that'll come with a speed loss, so
>it makes sense to try to avoid that.
>
>Since qsearch tends to amount to a large % of the nodes searched,
>this sounds like an understandable decision.
>

It's possible that a large reported qsearch is either the result of counting
nodes differently than other progs, or doing checks, or both.  I count nodes in
make_move, and test for checks only in the first ply of qsearch, which results
in about 50% qsearch vs internal nodes.

It's odd, but I think if people aren't aware of differences caused by how nodes
are counted, they may spend time trying to fix things that aren't broken, or
vice-versa.

Will



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.