Author: Bruce Moreland
Date: 09:29:40 09/02/01
Go up one level in this thread
On September 02, 2001 at 07:29:12, Uri Blass wrote: >My question is when it is a good idea to define global variables >instead of local variables > >There are some variables in my move generator that originally >were defined only as local variable in some procedures >(I do not need their value when I am not in the procedures) > >I found a trick to make my program slightly faster by defining them >also as global variable and not using them as local variables in part >of the cases. >My question is if there is a rule to know when to delete them >as local variables >I found that in part of my procedures using them as global >varaibles make my program sligtly faster. >when in another part of the procedures >it makes my program slightly slower. > >Is there a way to know when it is faster >without testing for every variable? > >I use visual studio 6 and I also chose >optimize for speed in my project. > >Uri In my experience, programmers have a hard time dealing with tradeoffs between performance and maintainability. I have seen cases where programmers attempt to optimize everything immediately. Some people would call this premature optimization, but some of these cases optimization is not just premature, it's not necessary at all. In another case, a team leader insisted that our group not concern itself at all with optimization until we were pretty close to a deadline, at which point he figured out that we were glacially slow, and that many design decisions had been made and built upon, which made fixing this problem impossible. Chess programs need optimization in a great many places, and the move generator is obviously one of them, but even so, it's important to decide exactly how much of your soul it is desirable to sell. If you are talking about making your code look very strange in order to get an extra 1% out of one area of the code, that is a high price given that 1% of a fraction of total execution time is not very much. If you are talking about a single function with some locals declared at the top, as opposed to the same case with a few of those locals declared as "static", I suggest that speed improvements in this case are coming as a result of compiler randomness. Compiler randomness can't be counted on to stay the same from day to day, and I don't think it makes any sense to count on it, especially since there is a definite down-side to screwing up a function like this. The function is no longer re-entrant. If you have anothe thread calling this function, you eat the static variables while someone else is using them. If you have one function that calls another, and both use a big wad of shared data, I can imagine a performance increase here that's not due to compiler randomness. If you make the big wad global, you don't have to pass a pointer to it to the second function, I can imagine a performance improvement that's not just due to compiler randomness. In one case, you have a function that has to get at its data via a pointer, and in the other case you don't. This also has the problem with re-entrancy, so if you go for this performance improvement you've saddled yourself with a "thing" you have to remember forever. If your program is new, don't worry about this kind of nonsense yet. You probably have huge performance gains that can be made because functions that are simply inefficient, and you can probably get huge performance gains by ordering moves better and pruning crap out of your tree. bruce
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.