Is a binary on 32 bit faster than a 64 bit binary in solaris ?

Question

I timed a program for both 64 bit and 32 bit . The code is something like this --
#include<stdio.h>
#include<string.h>
#include<stdlib.h>
int main (int argc,char **argv)
int count=0;
int count2=0;
int u=0;
int count3=0;
int sizeoffile=0;
int sizefile[5];
for(u=0;u<5;u++)
sizefile=1;
printf("%d\n",sizefile[u]);
char a='a';
char *b ;
FILE *file ;
b = (char *)malloc(512*sizeof(char));
while(count <512)
strncpy(b+count,&a,1);
count++;
for(u=0;u<2;u++)
sizeoffile=0;
if(u==0)
file=fopen("./writesize1","a");
else if (u==1)
file=fopen("./writesize2","a");
else if (u==2)
file=fopen("./writesize3","a");
else if (u==3)
file=fopen("./writesize4","a");
else if (u==4)
file=fopen("./writesize5","a");
while(sizeoffile<sizefile[u])
while(count2<(1024*1024))
count3=0;
while(count3 < 2)
fprintf(file,"%s",b);
fprintf(file,"\n");
fflush(file);
count3++;
count2++;
count2=0;
// count3++;
count3=0;
sizeoffile++;
fclose(file);
return 0;
The above code is crude code to write files of 1 GB.
I timed the above code binaries for 32 and 64 bit on a solaris 10 box . I got the following times :
for 32 bit : 2.16796for 64 bit : 2.5039466
Is this the expected behaviour or something I am missing ?
Edited by: rarpit on Mar 18, 2009 9:59 PM

Answer 1

Reasons a 64-bit program might be better:
* Can directly access more than 4GB of VM
* Has direct access to 64-bit math routines
* On x86, has access to more registers (big win for some code/compiler combinations) Shouldn't affect SPARC much.
Reasons a 32-bit program might be better:
* Can run on both 32-bit and 64-bit kernels
* Pointers are smaller. More code can fit in CPU cache, may run faster
* Memory footprint slightly smaller due to smaller pointers
So the general case is that unless you need the extra VM space, 64-bit math, have a special need to access 64-bit libraries, or your compiler is doing a great job of using the extra registers on x86, there's not much benefit to creating a 64-bit binary.
All that said, your program appears to be writing large files to disk. That task should be completely dominated by your I/O times. Did you run them more than once? I would imagine both versions to be identical because anything other than the disk writes will be in the noise.
Darren