Author: Álvaro Begué
Date: 06:06:59 08/10/04
Go up one level in this thread
On August 10, 2004 at 06:05:57, Alessandro Scotti wrote:
>On August 10, 2004 at 05:27:54, Uri Blass wrote:
>
>>some reasons:
>>1)I understand that I need to get rid of them if I want to have an SMP version
>>in the future.
>>
>>2)Speed.
>>I believe that remembering a lot of global varaibles is not the fastest way for
>>chess programs and it is better to remember a varaible only when you need it
>>becaause there is limited space in the fast memory.
>>
>>3)Clarity
>>It is better to have all the time related information in one place in the
>>program and when I use it in many different places understanding what is going
>>on is harder.
>>
>>4)Bugs
>>With a lot of global varaibles I may do a mistake and change a global varaible
>>that I do not mean to change(espacially when there are varaibles with different
>>names).
>>Without global varaible if I need to call a special class the risk for a mistake
>>is smaller.
>>
>>Uri
>
>Ok I start to understant better now! :-)
>
>1) I haven't experience with SMP but in general the approach I prefer is to
>study a problem and develop at least a tentative design before writing code.
>Otherwise, there is the risk of doing work that one think *could* be useful but
>eventually isn't.
At least it is clear that in SMP programming, you are not going to get away with
having a single global board on which you make and unmake moves. I think 1) is a
valid point.
>
>2) I'm not sure you're going to gain speed by eliminating globals, and actually
>you could possibly lose some by moving them to an object because sometimes the
>extra indirection may cost a bit. But it's not at all easy to predict how these
>modern processors behave, I have found some really counter-intuitive cases on
>occasion.
Fair. There is nothing slow about globals. They are ugly and messy, but not
slow.
I once made a very basic chess program with a single global board and an
identical program in which the pointer to the board had to be passed around. The
first one was about 15% faster. You can avoid the indirection using templates,
but it's a little tricky, and not much cleaner than having a global board.
>
>3) A really good point and I like to keep my stuff well organized too. For this,
>I find the "static" keyword very handy, for example:
>
>struct Score {
> static int bishopValue;
>};
>
>It behaves like a global (there is no need to have an instance of Score) but I
>find it more readable and less error prone as code must then explicitly state
>where the variable comes from:
>
>if( material >= Score::bishopValue ) ...
If you are never going to have an instance of "Score", it shouldn't be a class.
Use a namespace for that:
namespace Score {
const int bishopValue=315;
};
>
>If needed (say, when done with experiments) static variables can also be
>replaced with compile time constants by declaring them with enum inside the
>class: that could speed up things a little.
const variables are as fast as enums.
>
>4) I think this is partially addressed by 3, but of course programming with all
>those globals (whether wrapped in some class or not) definitely requires special
>care...
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.