Author: Dieter Buerssner
Date: 14:46:31 06/25/04
Go up one level in this thread
On June 25, 2004 at 17:10:22, Gerd Isenberg wrote: >OTOH the generated_moves[] array "allocates" always about 4K on the stack frame >per search/qsearch call. If only a few captures, or even no move at leaf nodes >are generated, or if you generate not all at once, the whole array is a kind of >"wasted" stack ressource. If you call eval at some leaves, you often have nply >gaps inside your valuable fast stack - nply pages. How deep do you search pawn >endings? Never more than 126 plies :-) I just calculated for another discussion the maximum number of pseudo legal moves (an upper bound of it). 323 moves will be enough for legal chess positions. 9 Q, 2 R, 2 B, 2 N, 1 K 9*27+2*14+2*13+2*8+10 (including 2 castling moves). 323*8 + 256 + some overhead -> about 3 kb per recursion level. I phrased it wrong or ambigiously. I don't use the generated_moves array (yet). But I want to try it. I used this in my Kalah program. I am using the local array for the PV. >IMHO, saving some index or two per node (nextget, nextput), accessing an one >dimensional stack like array seems more ressource friendly to me, specially if >you don't generate all moves at once. > >I guess that safes some 4K pages, may be not important if you have enough. >But i like to waste it elsewere ;-) It will be hard to guess, without trying it out. Unfortunetly my data is not that well hidden, to try it out really fast. For example the move sorting will just access the global move stack, and must be changed a bit. The move generation already gets a pointer to an area, where it fills in the moves, so it should work unmodified. Cheers, Dieter
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.