Author: Robert Hyatt
Date: 18:45:28 09/02/01
Go up one level in this thread
On September 02, 2001 at 10:32:40, Uri Blass wrote: >On September 02, 2001 at 09:44:53, Robert Hyatt wrote: > >>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 a few issues: >> >>1. If you want a variable to maintain its "state" across procedure calls, >>then it should be either global, or static in that procedure. There is no >>real difference between the two. >> >>2. If you want a variable to be visible in multiple procedures, then you >>can either make them global for the entire program, or just global to a >>specific set of procedures, whichever you prefer. > >I think about variables that I do not care about their value >when I am out of the procedure so changing them to be global >varaibles is not going to change the program except speed. > >I started by doing these variables only local variables but >decided to test the option of doing part of them global variables. > >I found that defining them as global variables and using them as >global variables only in part of the procedures could make my program >slightly faster in doing the same thing and the question is >if there is a way to find the relevant procedures for every variable >without testing run times. I don't see why local variables would be faster or slower than global variables. Locals are accessed as offsets from a fixed point in the stack. Globals are accessed directly. I don't see any real reason why one would be faster than the other. More likely it is an issue of locality. Variables that are used close together in time should be stored close together in memory to take advantage of the way a cache line fill sucks in thirty-two consecutive bytes in memory... That can pre-fetch important data if it is stored in the correct order in memory. > > > >> >>3. If you have plans for a parallel search, and you modify global variables >>as part of your tree search, this won't work in a parallel search, because >>the multiple threads will share those global variables making them useless >>if they are being modified, unless you start locking/unlocking them. > >I do not plan parallel search in the near future >I even do not have a chess program and only a legal move generator >and my plans in the near future are only to try to do it faster >without losing information that it generates. > >I almost did not work on my move generator in the last month >but I decided to think about it again. > >It is slightly slower than Crafty in calculating perft 6 from >the initial position. >> >>There is no performance issue at all in the use of global and local >>variables, if they are used in a single procedure. Otherwise you need some >>way to let multiple procedures see a local variable, which generally means >>a formal parameter in a procedure call, which can hurt performance dur to the >>lack of registers on the X86 processors. > >I found that in part of the procedures using global variables >instead of defining local variables with the same name helped >the program to be faster and >in another part of the procedures the opposite happened. > >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.