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);


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.

  • \$\begingroup\$ 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. \$\endgroup\$ – Mike Dunlavey Jan 17 '12 at 17:48

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.

  • \$\begingroup\$ 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. \$\endgroup\$ – Michael Banzon Jan 11 '12 at 20:38
  • 2
    \$\begingroup\$ (I hope you meant shift operation.) \$\endgroup\$ – Mike Nakis Jan 11 '12 at 20:52
  • \$\begingroup\$ That's great. Can you please post your findings for the benefit of those who might read this post in the future? \$\endgroup\$ – Mike Nakis Jan 11 '12 at 20:52
  • \$\begingroup\$ haha - SHIFT-operation - yes ;-) \$\endgroup\$ – Michael Banzon Jan 11 '12 at 20:54
  • \$\begingroup\$ I have added the solution findings. \$\endgroup\$ – Michael Banzon Jan 11 '12 at 21:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.