Author: Uri Blass
Date: 03:23:51 12/06/02
Go up one level in this thread
On December 06, 2002 at 05:42:06, Richard Pijl wrote: > >>>>My questions are the following: >>>>1)What statistics should I include in the bench commands >>>>to do it more productive. >>> >>>I haven't got much besides nodes either. I print only totals for the positions >>>together as the normal statistics output can be used per position (just type >>>'post' after starting bench). >>>The statistics printed for the total set are: nodes, qnodes, time and knps. >> >>I understand but in this way you cannot find a bug that happen only in games and >>not in analysis. > >I was under the impression you wanted to compare two versions of your program >and see whether you've broken something in optimizing it. If you have broken >something in search, eval, move generation it is very likely to show up in >there. But this of course always depends on the positions chosen in the bench >command. Yes I wanted to compare two versions for testing the optimization but there are things to break that are not discovered by a test suite. I discovered it when I tried version B in games and found that B claimed mate against gerbil in fast game when there was no mate. It turned out that the problem was that movei did not update some information correctly after making the user move but when I ask it to search positions there is no user move so there is no problem. Another problem is that I found that the result of a position may be dependent on the analysis of position that was before it(this problem was not related to the optimization but my first thought was that I had a new bug) It turned out that there is a small partial extensions that I do only when the last 2 plies are captures and the last 2 plies are calculated from the hist_dat table. I did not updated the hist_dat table after setting up a new position and when I set up a new position when black starts movei believe that it is the second ply of the game so movei used information about the first ply of the search to decide about extensions. > >>possible ideas to catch more bugs are also to tell the program to play against >>itself in fixed depth and count nodes to finish the game but I wait to hear from >>more expereinced programmers. > >I don't think you will gain much by it as it requires a lot more execution time. >And making search more shallow probably won't do much good. My example prove that it may catch bugs that only test positions cannot. > >I've seen problems where node count started to differ only at ply 5 or 6, and >not in all positions either. So a deeper search on positions with the potential >of having for instance weird ep problems might do you better than having many >positions on a shallow search. I agree that good positions are needed to catch problems. >To find hashtable reuse/aging problems two moves in a row might be useful >though. I haven't tried that one yet. Movei still does not use hash tables in an effective way so it clear the hash table after every move except fast blitz. I find other ideas more interesting to experiment with. The last optimization of my move generator that I started is about pins and the reason is not only doing the move generator faster but being able to do things faster in the evaluation. Movei has a pin array that tell it for every square if the piece of it is pinned to the king and the direction that it is pinned. usually no piece is pinned. This way of data is not good because if one piece is pinned I have no fast way to find the square of the pinned piece. I think that it may be more productive to compress the information to one integer so I can get the square of the pinned piece from it and more data but as first optimization I decided to have an array that is the number of pinned pieces for every ply so when movei undo move it does not need to calculate the pin array when it finds that the number of pieces that are pinned are 0(at this moment I even have not this and movei simply memset the array when the number of pinned pieces is 0). The bug that I found only in games and not in test positions is that movei did not update the information about number of pinned pieces correctly after doing the user move or after undoing moves. I already fixed it simply by always calculating the pinned pieces before generating moves when I am not in the main search(it may be not the fastest way to do it and maybe I do not need it in part of the cases and I can simply update it by one = when I need it but I do not care about this speed problem when I am not in the search function). Uri
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.