Author: Jens Kahlenberg
Date: 01:50:04 07/05/03
Go up one level in this thread
On July 04, 2003 at 17:39:07, Uri Blass wrote: >On July 04, 2003 at 17:26:31, Normand M. Blais wrote: > >>On July 04, 2003 at 16:03:32, Jens Kahlenberg wrote: >> >>>On July 04, 2003 at 14:26:42, Normand M. Blais wrote: >>> >>>> ... >>>> >>>>I agree with you that he first version is problematic. But I was thinking that >>>>pointer arithmetic would be fast. And, the fact that it was running ok under the >>>>debug version (and the release version with default optimization) lead me to >>>>believe that the code was correct. >>>> >>>>NMB >>> >>>Hi Norman, >>> >>>Rule 1: Always regularly test both the Debug and Release mode versions of your >>>applications. (taken from http://www.codeguru.com/debug/ReleaseMode.shtml) >>> >>>BTW: 'regularly' comes close to 'daily' :-) >>> >>>Regards, >>>Jens >> >>Jens, >> >>Funny enough. I more often program in release version than in debug version. >>Only when I have a problem that I use the debug version. When I test the program >>using specific positions, I need the speed. >> >>Regards, >> >>Normand > >I also use most of the time the release version but I care to use the debug >version less often only to see that I get the same number of nodes as the >release version. > >Uri Hi Normand and Uri, First of all, please carefully read http://www.codeproject.com/tips/optimizationenemy.asp to understand why i wrote "Optimization is the beginning of all evil" in that thread some days ago. You should have stumbled over Mr. Newcomer's essay if you followed my link there. BTW, my remark is a slight modification of Donald Knuth's viewpoint who said "_Premature_ optimization is the root of all evil". Of course chess programmers will answer "On the other hand, we cannot ignore efficiency" (John Bentley) and they are right. But please don't blame your compiler if things go wrong or your code is not efficient enough, because code optimization is one of the trickier jobs for a compiler and will ever(?!) be a either errorprone or inefficient. Better profile your program and only optimize the hotspots (Norman's code example is _of course not a hotspot_). Put your hotspots in a library and always link its release version. And your need for speed should be satisfied. There's another "debugging" technique, that might meet your debug version aversion: "You can debug a release version of the program; just go into the C/C++ tab, select the General category, and select Program Database for Edit and Continue. You must also select the Link tab, and under the General category, check the Generate Debug Information box. In particular, if you have turned off optimization you have the same debugging environment that you had for the debug version, except you are running with the non-debug MFC shared library, so you can't single-step into the library functions. If you have not turned optimizations off, there are ways in which the debugger will lie to you about variable values, because the optimizations may make copies of variables in registers and not tell the debugger. Debugging optimized code can be hard, because you really can't be sure of what the debugger is telling you, but you can be further ahead with symbols (and line backtrace) than without them. Note that statements can be reordered, pulled out of loops, never computed, etc. in an optimized version, but the goal is that the code is semantically identical to the unoptimized version. You hope. But the rearrangement of the code makes it very difficult sometimes for the debugger to tell the exact line on which the error occurred. Be prepared for this. Generally, you'll find the errors are so blindingly obvious once you know more-or-less where to look that more detailed debugger information is not critical." (thx to Mr. Newcomer) For further debugging techniques in release version i recommend http://www.cygnus-software.com/papers/release_debugging.html Regards, Jens
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.