Author: Dieter Buerssner
Date: 07:25:15 11/17/00
Go up one level in this thread
On November 16, 2000 at 10:33:48, Robert Hyatt wrote:
>On November 16, 2000 at 05:38:02, martin fierz wrote:
>>i have another question about speed: i'm using large arrays for different
>>things, hash-xoring, bit-counting, some arrays in the evaluation etc. i noticed
>>that the final speed of my program depends on how i declare them - but the
>>behavior seems rather erratic. does anybody know if there should be a difference
>>between declaring globals like this:
>>
>>int large_array[BIG_NUMBER];
>>
>>or
>>
>>int *large_array;
>>
>>followed by a malloc in the initialization?
>
>They are equivalent, actually, since C doesn't really have an "array" data
>type.
I think, it is very risky, to say they are equivalent. They are certainly
different. They are used in the same manner usually. But they are implemented
different. They are of course the same, when they are in the list of
parameters to a function.
>One of the things that students have trouble with is that if you use
>the pointer declaration form above, you can do this:
>
>*(large_array+i)=0;
>large_array[i]=0;
>
>even though the large_array declaration is not an array...
This of course is true. And also any compiler I have tried will produce
the same code, for both statements.
> because arrays
>are implemented in C via pointers.
Hmm. I think this cannot hold.
with
#include <stdio.h>
int *p;
int a[4];
int main(void)
{
printf("sizeof p: %lu, size of array %lu\n",
(unsigned long) sizeof p, (unsigned long) sizeof a);
return 0;
}
You will see two different outputs in general. On many typical implementations,
you will see 4 and 16.
Also, if you look at the asm output (x86, ATT Syntax, which means target,
source are reversed) of GCC of the following:
extern int *p;
extern int a[];
void foo(void)
{
p[0] = 0;
a[0] = 0;
}
.file "d.c"
gcc2_compiled.:
___gnu_compiled_c:
.text
.p2align 2
.globl _foo
_foo:
movl _p,%eax
movl $0,(%eax)
movl $0,_a
ret
You see, that different code is (and must be) produced for the array and
the pointer. To access the pointer, two instructions are needed, while
addressing the array, only one instruction is needed.
Also assume some student that writes in data.c
int array[4]
and in data.h
extern int *array; /* Robert Hyatt told me, that arrays and pointers are
equivalent ;) */
/* extern int array[] would of course be needed */
and in main.c
...
array[0] = 0; /* Segmentation fault */
So, together with the fact, that the "equivalence" for arrays and pointers
doesn't generalize to 2 dimensional arrays vs. pointer of pointers, to
me this shows, that there really os only very little equivalence at all.
To be a little bit on topic. For chess programs the array can be faster,
especially when they are only used once at a time. Here hash values
and piece square tables come to mind.
>>and when i'm using an array in the evaluation function, should there be a
>>difference between declaring the array as either a global array, or
>>alternatively declaring it in the function as static int array={1,2,3,...}?
^^^^^^
>Global may be faster. local will require using the stack and an extra
>register possibly. If the X86 had a reasonable number of registers, this
>wouldn't be a problem at all.
Not the static above. In typical implementations, no stack will needed at
all. Neither will be any register more needed, than with the global array.
The produced code will be identical, to the code produced with the global
array. The only difference will be, that the name will be hidden outside
of the function, and perhaps, that the data will be at another place in
the executable. But it will still be in the data segment, and not on the
stack. (When static const int array[4] = {0,1,2,3}; is used, the data may
be in the code space).
In my opinion, it is good practice, to hide the name outside of the function,
when the date needs only be accessed inside on single function. I cannot see
any disadvantage in principle.
Regards,
Dieter
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.