Author: Vincent Diepeveen
Date: 15:01:58 06/16/05
Go up one level in this thread
On June 15, 2005 at 16:36:54, Eric Oldre wrote: Of course the more time you invest in debugging the better. Apart from boundschecking with a real boundschecker; gcc has a great boundschecker extension at their homepage, windows has nothing that impressed me in fact like devpartner doesn't even find the most obvious boundsbug in my GUI. Further there is normal debugging ways, the most effective way in which i debug Diep if there is problems is in the next trivial way: That simply printing the entire search tree to disk. That can be done either direct or indirect : example output (written by hand just to show example now for 4 processors) : 0... searching root 0... makemove a2a3 0... a2a3 makemove d7d5 0... a2a3 d7d5 eval -0.200 0... a2a3 d7d5 ab=[0.001;0.002] cutoff -0.200 ... And when processor 1 is doing an action : .1.. blabla In short this is a very powerful way to debug search or debug parallel bugs. Of course for tough race conditions in a parallel search it is not so clever to directly print to textfile, as the time spent to print is too long (which means a deadlock or race conditions will happen not so soon as the time spent to printing is too huge). So i print it in a shared block of memory (locking first of course) and later parse that memory block to the above text. In this way i managed to debug the parallel search of Diep. For single cpu just printing directly to disk will do fine and you can examine how big your trees get at small search depths up to a ply or 6 is no problem. You'll find many weird stuff in your qsearch and your move ordering like this. Of course it's time consuming to do the above (reading those huge textfiles) but it's very rewarding. The above has another huge advantage and that it is finding bugs in your evaluation function and directly gives you an answer whether a new compiler sucks, is dangerous to use or whether you have a so far unfound bug which boundscheckers didn't find. That is, provided you also print the evaluation score in the textfile. You can compile at different platforms with different type of compilers your code and just compare the textfile verbose. If it is not 100% similar, then obviously there is a bug somewhere. This really will remove about all nasty to find bugs in your entire search&evaluation function. It is the by far the best test to see whether a new compiler has bugs. Especially many intel compilers and certain gcc compilers did not pass this test in past when using -O3 or in case of intel just -O2. gcc 3.3.x and 3.4.x was real real buggy here. 4.0 is far better. Of course the fact that you *seriously* look to debugging methods in your engine already means that your thing is going to be more bugfree than majority of amateur programs. Most haven't heard in fact from the word 'boundschecker'. The fact that out of any random compiler with this trick i can find optimizations that produce bugs, tells me how poor the different compiler teams are in debugging their compilers. Diep is not using any difficult casting construction or so, i never take risks there. Additional it is 100% integer code, so no floating point tricks are possible for compilers. Especially the GCC team is the most horrible code writing team on planet earth. Like 99% of their releases suffers so much from bugs that i can't even compile with -O3 without catching bugs. Obviously that i can prove that with such a simple debugging method is telling really a lot about how powerful the verbose printing method of a search is. >I was wondering if anyone would like to volunteer any tricks they've >used to help find certain bugs in their search function. >I think that the ideas of using perft for move generation and >reversing the board to find bugs in the evaluation have both >been really useful to me. I was wondering if anyone has used >techniques similar to these to help find search bugs. > >I understand that just because a engine can properly pass these >and other tests doesn't mean it's free of bugs. But they certainly >help detect at least some of them. > >I'm certain that there must be plenty of bugs in Latista's search >and I think it's time for me to work on discovering them. If >you don't have any automated tricks like above. Does anyone >have any general advise to help me spot some bugs? > >Eric Oldre > >PS. I have at various spots in my program tried to follow a similar >model of asserts as in fruit. I'm sure taking some time to >do this at more parts of my program would help.
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.