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.