Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: The need to unmake move

Author: Johan de Koning

Date: 19:01:59 08/25/03

Go up one level in this thread


On August 25, 2003 at 11:34:23, Robert Hyatt wrote:

>On August 25, 2003 at 01:57:36, Johan de Koning wrote:
>
>>On August 24, 2003 at 21:52:37, Robert Hyatt wrote:
>>
>>>On August 23, 2003 at 02:34:05, Johan de Koning wrote:
[...]
>>>>I was only joking, but if the q-search shows such kind of behavour *regularly*,
>>>>there something fishy going on.
>>>>
>>>>About half of the q-nodes have no children because of rep, mate, eval>=beta, or
>>>>all captures futile (according to a quick test, too lazy to do a decent test).
>>>>This could still mean that most horizon nodes are childless, while some spawn
>>>>very long narrow lines. However, I consider this most unlikely.
>>>
>>>Remember I _only_ do captures and pawn promotions to Q in the q-search.  No
>>>reps therefore.
>>
>>If you don't do any checks there should be even less deep and narrow lines.
>>After all, that was your point: deep narrow lines have a hich cache cost per
>>node. My point is that you're right, but is *should* happen very infrequently.
>
>
>The q-search as an unusual animal.  With queens on the board, it is amazing
>how the two queens can infiltrate and "eat" away on the other's material, for
>many plies.  :)
>
>10 plies is trivial.

Trivial as in every day, but not every millisecond I might hope.
Subtrees like this don't add anything to the purpose of the q-search: avoiding
huge errors (that are cheap to spot) at the search horizon. So if they threaten
to become a pest they should simply be truncated.

>>> When I make a move, I _must_ go to the next ply, and see if
>>>there are any captures.  I do the copy when I do the make to get to the next
>>>ply.  It becomes expensive.
>>
>>When you make a move, you *must* be prepared for the next ply to return. :-)

I was trying to say it doesn't matter *when* you do it, it's total amout of work
that counts. Copy + update versus prepare_undo + update + downdate.

>That was the point I think.  There are so many copies, of an array, that (for
>Crafty) it was significantly faster to avoid the copy and keep the bitmaps in
>cache.

Though I still doubt the cleanliness of the comparison, I'm willing to accept it
was faster *then*. I am however sure that on slightly newer processers it will
not be significantly faster, maybe even not faster at all. Unless your Xeons
"suck" at blockmoves.

... Johan



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.