Author: martin fierz
Date: 08:41:59 01/06/04
Go up one level in this thread
On January 06, 2004 at 11:35:42, Gerd Isenberg wrote:
>On January 06, 2004 at 10:56:00, martin fierz wrote:
>
>>On January 06, 2004 at 09:40:33, Robert Hyatt wrote:
>>
>>>Maybe there is some confusion here. There is _no_ cost for "allocating"
>>>local variables in a function. And I _do_ mean _NO_. These values are
>>>simply "on the stack" and when the function is entered, the stack pointer has
>>>some constant subtracted from it to leave a "hole" that is used to hold local
>>>function variables. no malloc() or anything like that is done by modern
>>>compilers, hence zero cost.
>>
>>hi bob,
>>
>>is this really true? i used to have a HUGE structure describing a move in the
>>first version of my chess program (don't ask, please...). in my negamax function
>>i had this
>>
>>int negamax(int alpha, int beta, int depth)
>> {
>> MOVE movelist[MAXMOVES];
>> ...other variables...
>>
>> ...typical negamax code...
>>
>> }
>>
>>i saw clear speed differences depending on the value i used for MAXMOVES - and
>>in my tests, i made sure that using 100 would never overflow in the positions i
>>was searching, then i set it to e.g. 200 and the program would get a few %
>>slower, although these additional 100 array elements were never used.
>>
>>how can this be explained? i'm not memsetting the array to 0 or anything.
>
>Hi Martin,
>
>that was my point in my reply to Bob - instruction length.
>
>Did you expect the assembly,
hi gerd,
for heaven's sake no! to me, __asm is about equivalent to chinese, i'm not an
expert like you :-)
>specially the bp-relative offsets of the other
>locals load/stores? In C, per default all locals of a function on the stack,
>including actual parameters are addressed relative to the base pointer register.
>As long those offsets are in a signed byte range (-128..+127), with X86-32 only
>one byte (to sign extend) is necessary, otherwise the complete 32-bit offset is
>needed.
...and this sounds a bit like chinese too! forgive me for my stupidity in this
area! are you saying that if the storage of my locals exceeds X bytes (X=256?),
then my function will get slower? and that the execution speed of my function
would depend on the storage amount in a step-like way: locals need less than X
bytes => fast; else => slow?
because that is not what i saw. i didn't measure exactly, but the larger i made
MAXMOVES, the slower the program got.
cheers
martin
>
>Gerd
>
>>
>>like uri, i thought the program was allocating memory every time it entered the
>>function, and that that was taking time. i ended up making my MOVE variable much
>>smaller - although it's still much larger than crafty's :-)
>>
>>i thought perhaps i should allocate the movelist beforehand as a global, like
>>this:
>>
>>MOVE *movelist[MAX_SEARCH_DEPTH]
>>for(i=0;i<MAX_SEARCH_DEPTH;i++)
>> movelist[i] = malloc(sizeof(MOVE)*MAXMOVES)
>>
>>and then in the negamax function use the appropriate movelist for that search
>>depth. that turned out to be significantly slower than the local variable
>>approach. again, i don't understand why that would be... - anyone?
>>
>>cheers
>> martin
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.