Comparing 32- and 64-bit

Question

A few days ago I saw this question on Stack Overflow.

I have tried to make a little demo to show the speed advantage of using 64-bit memory operations compared to 32-bit ones. So I wrote this code:

#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>
#define MEGABYTES 1024 * 1024
#define MEMORY_SIZE 100
#define LOOPS_START 100
#define LOOPS_STOP 10001
int main (int argc, const char * argv[])
{
 clock_t start, stop;
 int64_t* big_pile = malloc(MEGABYTES * MEMORY_SIZE * sizeof(char));
 for (int loops = LOOPS_START; loops < LOOPS_STOP; loops += 100)
 {
 start = clock();
 for (int i = 0; i < loops; i++)
 {
 for (int pos = 0; pos < MEGABYTES * MEMORY_SIZE * sizeof(char) / sizeof(int64_t); pos++) {
 big_pile[pos] = big_pile[pos] ^ big_pile[pos];
 }
 }
 stop = clock();
 double elapsed = (double)(stop - start) / CLOCKS_PER_SEC * 1000;
 double average = elapsed / loops;
 printf("Loops:\t%i\tElapsed time:\t%f\tAverage:\t%f\n", loops, elapsed, average);
 }
 free(big_pile);
}

I compile it under XCode on a MacBook Air running OSX Lion. This allow me to change the build target to 32- or 64-bit. When I run the program (and verify that the program is actually running in the correct bit-mode) I see no real difference in time.

Is this the right way to measure performance difference between 32- and 64-bit? Is XCode/the compiler playing tricks on me? Is there anything else wrong?

Note Sorry for the C. C isn't my native tongue ;-)

---

Solution findings

Writing 100 MB memory executing in 64-bit mode using 64-bit integer pointers takes ~47 seconds. Exceuting in 32-bit mode using 64-bit integer pointers takes ~70 seconds. Executing in 32-bit mode using 32-bit integer pointers takes ~90 seconds.

• Mike Dunlavey: There may be applications where this kind of loop is the "bottleneck". All the serious apps I've seen have call stacks ending, nearly all the time, deep in system code, 3rd-party libraries, or I/O. 64-bitness is totally irrelevant in such code. All it really does is allow addressing memory beyond 4G, or allow random access in humungous files, giving people one less reason not to write piggy code.

Answer 1

You are using int64_t, so most of your code gets compiled into the same machine code regardless of the bitness of the target. Also, A^A = 0, so the compiler might be optimizing your entire for loop with a single call to memset with zero.

I would recommend that you move different values around instead of xoring the same values together, and I would recommend that you use int32_t for the 32-bit version, and int64_t for the 64-bit version.

• Michael Banzon: Thank you for the answer. There is a huge difference running with int32_t instead of int64_t when compiled for 32-bit. The obvious (but maybe wrong) assumption is that the compiler don't really do a lot to optimize the code for 64-bit(?). When using a shit-operation instead of the xor there is HUGE differences between the 32- and 64-bit versions no matter what int-type I use.
• Mike Nakis: (I hope you meant shift operation.)
• Mike Nakis: That's great. Can you please post your findings for the benefit of those who might read this post in the future?
• Michael Banzon: haha - SHIFT-operation - yes ;-)
• Michael Banzon: I have added the solution findings.