Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: What is the branching factor for this position?

Author: Larry Griffiths

Date: 15:46:55 08/11/00

Go up one level in this thread



>
>This is very interesting since it make me think about my recent speeding of my
>brute force search. Idea (said repeatedly by Bob and Tom) that illegal move
>generation have more sense that legal, because of effective alpha-beta cuts. I
>could not see. This is because I knew that average branching factor is between 4
>and 7. Mainly around 5.5 for my program. With this number of moves to verify
>later, I have seen little chance to speed my program. What I found later is
>slightly more that 50% of all search in each ply is done after the first move
>was seen. So idea of using illegal moves have sense. Just try for start one
>illegal best move and only if this not work go into long legal moves generation.
>Still legal move generation have its sense for efficency in my program.
>
>
>
>
>Probably your number confirme mine. Since I spoke with you last time, I went to
>see this position with my special counter. This counter (I described it before)
>say average number of legal moves for each ply for given position. It calculate
>and say in the same time average number of legal moves that this part of program
>generate in one second. Search was done 8 plys deep. AMD 400Mhz.
>
>For black: 30 moves average for each ply. 1132k average legal moves generated
>per second.
>
>I forgot to see average NPS that this program also say when it search average
>number of moves per ply. But I have for normal search indication: 287k. Above
>search must give around 45% higher number. Should be above 400k.
>
>For white: 31 moves as average for each ply. 1100k average number of legal moves
>generated per second. For normal search NPS is indicated as 339k. For this
>search must also go beyond 400k.
>
>Uniform plys structure produce higher NPS numbers.
>
>Your numbers are probably so high because they are illegal. Make and unmake the
>position don't consume that much time in average program. Even sorting of moves
>is not time consuming. Generation of moves it is where all the time goes. Our
>numbers of move generation I see as very close.
>
>Leonid.
>
I do not include illegal moves when I calculate my Moves/captures per second.
Illegal moves mean that I made a move and the opponent captured the king at the
next ply, so the opponent returns that the move was illegal.

I do not consider my numbers to be so high.  I am using mostly bitboards for
move generation so that I do not have to generate all moves when I enter a ply.
I generate captures and then go deeper into the tree.  If a cutoff occurs, then
I do not incur the overhead of generating moves (non-captures).

I believe bitboard move generation is slower than other methods.  I think it may
really shine when used with alpha-beta pruning.  My moves per second drops to
around 1 million a second when I use alpha-beta pruning.  I also incur extra
overhead because alpha-beta also includes an evaluate function and the
alpha-beta code.  I am trying to implement a recursive alpha-beta function into
my program at this time without success.

Larry.



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.