Author: Anthony Cozzie
Date: 08:21:44 06/27/03
Go up one level in this thread
On June 26, 2003 at 22:45:17, macaroni wrote: >I recently wrote a computer chess program, using alpha-beta, null moving, and >quiescent search, in the main search function I use a history heuristic to sort >moves, and that seems to be doing just fine, I can't say the same for my q >search, the sorting procedure I use for that, is biggest capture, smallest >attacker. However, when I do a ply 5 search, i get 23,000 standard search nodes, >which seems acceptable to me, but I get 180,000 q nodes, which seems ridiculous. >Is this as bad as I think it is? is it expectded? should I just make my Eval, >MoveGen, MakePosition and UnmakePosition functions faster (if possible)? Also, >my program manages 75,380 nodes per second, is this high? someone once told me >that a high node/sec count is not always good. >Thanks everyone look up ernest heinz's article on futility pruning. I use a slightly more complicated move ordering, but MVV/LVA + futility pruning will get you to a 1:1 or 1:1.5 Node:QNode ratio. 75knps is not good. A new program should have a very simplistic eval *and* relatively bad move ordering and pruning, all of which increase your nps. Assuming your hardware is reasonable (>1.5G athlon) I would say a program with a very basic eval should be somewhere around 400-500 kn/s. anthony
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.