Author: leonid
Date: 16:54:37 08/11/00
Go up one level in this thread
On August 11, 2000 at 18:46:55, Larry Griffiths wrote: > >> >>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. I read twice here about recursive alpha-beta fonction and tried it twice. For me it was double failure. Maybe I simply not captured the basic meaning and i was too lazy to go to read about it. Maybe... If somehow you will succeed in implementing this method later, please come here and say how it was done. If you will have free moment to say it. All the best in your writing! Leonid.
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.