Author: Gerd Isenberg
Date: 08:35:42 01/06/04
Go up one level in this thread
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, 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. 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.