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.01 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.