Author: Robert Hyatt
Date: 10:29:04 11/04/02
Go up one level in this thread
On November 04, 2002 at 09:39:14, Vincent Diepeveen wrote: >On November 04, 2002 at 06:40:14, Pham Minh Tri wrote: > > >I hardly use asserts in DIEP. If i need one i usually use a >printf, which gets removed using a // when it is tested well >and a year later or so removed. > >I guess bob has the same habit. Actually I have a lot of debugging code in crafty. I surround the debug blocks with something like this: #if defined (DEBUG) ... #endif I don't _always_ use DEBUG. I have DEBUGSMP so that I can just get the parallel search debug information without all the evaluation and search debug info. I also have a bunch of different DEBUG macros for evaluation so that I can just get the output from the particular piece of code I am working on. > >I boundscheck carefully though and if i detect a difference in >node count somewhere then i am going to check it out and do not >ignore it or claim the compiler is to blame :) > I thought you were claiming that the Intel compiler had many such bugs? :) >Note that it is a hard truth that compilers *do* make errors, >but in 99.99% of the cases it is a bug in the program, so finding >them happens very seldom. Basically i just found out some stupid >things in gcc and in intel c++. > >Best regards, >Vincent I think _the_ most common type of bug is unitialized data. That is almost _always_ the problem when a program changes its behavior when you insert a function call (such as printf()). And these bugs +must+ be found of course, or the program will always have a random component in the evaluation that will change when optimization level is changed, new functions are called, or a new compiler/computer architecture is used... > >>On November 03, 2002 at 13:47:57, Vincent Diepeveen wrote: >> >>>On November 03, 2002 at 12:23:50, Russell Reagan wrote: >>> >>>Do you have an assert for every index in your program? >>> >>>If not then a boundschecker might be an idea to try as well :) >>> >>>>What I usually do to find bugs is use the assert() macro (in assert.h, or you >>>>could write your own). Basically what you do is you assert things you know >>>>should be true, such as an index into an array being in bounds. If it's false, >>>>your program will halt and let you know where the error occured. For example: >>>> >>>>assert(i < MAX_VALUE); >>>>myArray[i] = SomeFunction(x); >>>> >>>>That way, when you run the program, it will make sure that i is within bounds. >>>>The cool thing about this is that it only does this in debug mode. In release >>>>mode the assert()'s go away, so there is no speed penalty. In my programs I go >>>>crazy with asserts, and put them all over the place, and it helps find some bugs >>>>I wouldn't have found without the asserts. Yes, it will run slower in debug >>>>mode, but the point of debug mode is to find bugs, not to run fast. >>>> >>>>Russell >> >>I agree that use of asserts in everywhere is one of the best experiences to >>share (including check bounds). Sometimes my new changes can trigger some dozens >>of asserts. Without asserts, my program can run two times slower in debug mode, >>but now, it is 20-30 times (in term of nodes per second) as slow as it in >>release mode. The big benefit is I can fast develop program, try many new ideas >>without worrying much about new errors. >> >>One of amazing thing to me is that I don't find out asserts in Crafty. So I >>guess Bob used a special program to clean up the developing versions before >>releasing. >>Bob, is it correct? Thanks :)
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.