3 replies to this topic

[Osnarf]

At least when compiled in Visual Studio 2005 Express. I ran this code below and was very surprised... i expected them to operate very similarly. However, the gap just kept increasing...
Btw, i know the pointer loop can be optimized, i just wanted to compare them side by side. When you increment the pointer, you get a slight performance increase over array indexing. However, the gap between those is not as big as the gap between indexing and straight arithmetic.
Can anybody Explain why this is?

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

typedef struct
{
     double array;
     double pointer;
}TIMECOUNT;

TIMECOUNT timeap = {0,0};
time_t start;
time_t stop;
double temp;
char array1[2000000];
int counter;
int i;
        
int main(void)
{
    char* p = array1;
    
	for(i=0;i<2000000;i++)
	{
		array1[i]=0;
	}

    start = clock();
    for(i = 0; i < 2000000; i++)
    {
          array1[i] = 65;
          array1[i] *= 20000;
          array1[i] = 20;
          array1[i] = array1[i]*array1[i];
          
          //putchar(array1[i]);
    }
    stop  = clock();
    temp = ((double )(stop - start))/((double )CLOCKS_PER_SEC);
    //printf("%f seconds array\n", temp);
    timeap.array+=temp;
    
    
    for(i=0;i<2000000;i++)
	{
		array1[i]=0;
	}

    start = clock();
    for(i = 0; i < 2000000; i++)
    {
          *(p+i) = 65;
          *(p+i) *= 20000;
          *(p+i) = 20;
          *(p+i) = *(p + i) * *(p + i);
    }
    stop  = clock();
    temp = ((double )(stop - start))/((double )CLOCKS_PER_SEC);
    //printf("%f seconds array\n", temp);
    timeap.pointer+=temp;
    
    counter++;
	if (counter%100==0){
		printf("\aMILESTONE\n");
		printf("-------------------------------------\n");
		printf("TotalTimes, Array = %.3lf, Pointer = %.3lf\n\n\n", timeap.array, timeap.pointer);
		if(counter==100000){
			system("pause");
			return 0;
		}
	}
        
    main();
}

When I say it can be optimized, i mean such as:

for(; p <= q; p++)
    {
          *p = 65;
          *p *= 20000;
          *p = 20;
          *p = *p * *p;
    }

Where q is the last element in the array.
Sorry for my sloppy coding, i just did it really quick b/c i was curious.

[Sysop_fb]

I'll admit I don't use visual studio but your title is only true under a multitude of different conditions.

Although the way you used the pointer is rather unfair in comparison. A pointer is meant to traverse not just sit at one spot and get incremented through memory however many bytes at a time the amount to be incemented growing and growing...
The index into an array is easy to do at guess I'm almost certain the compiler is just indexing it through using an register as an indexer (which is basically the same way a pointer would work in this circumstance) which going by your self proclaimed results I would have to assume the pointer code is not being optimized by the compiler probably because it assumes you want to keep track of that memory address.
Without going into some long long ramble on optimizing I'll just say this.
You're version of 'optimized pointer code' isn't 'optimized' it's just 'regular pointer code' or 'using the pointer how it's intended' that probably gets automatically slightly optimized similiar to how array indexing is done.
Doing a tests in my humble opinion similiar to this isn't a matter of 'comparing it side by side' which can lead to biased testing, it's seeing how they compare when utilizing each the way they were inteded to be utilized. Ofcourse with a lot of other considerations when it comes to testing in a real-world scenario.
/end ramble/

[Osnarf]

I never said that array indexing is a better way than pointers. I almost always use pointers anyways unless it's multidimensional. I use them the way i said is "optimized", although i'm sure that's not the optimum way to do it. There's always a better way.

All i said was that
array[i]
is faster than
*(p+i)

which i thought was odd b/c i thought they were the same thing essentially. isn't array[i] = *(array+i) = *(p + i) ??

[Sysop_fb]

You're getting confused about what's going to 'behave' similiarly. Two pieces of code might be required to behave the same but if one piece of code is a crappy piece of code and the compiler can't pick up corectly what you're trying to accomplish by doing it that way then it could lead to a slower running program.