> Just to state what might be obvious (but then again maybe not), it
> sounds like the original expectation was that in 64-bit mode, the
> 64-bit integers would be used to reduce the number of operations
> needed for a given input size. However, depending on how the
> libgcrypt code is written, this may or may not happen. IIRC, on
> Solaris (at least), in 32-bit mode, 'int', 'long', and pointer types
> are 32 bits (though you can still use 64 bit integers if you like), in
> 64-bit mode, the only ones that change are 'long' and pointer types,
> so if all the code uses '[unsigned] int' for all their types, all the
> code will still be using 32-bit integers (thus no possible difference
> if such a thing would have an impact).
My expectation was that something like the following loop would run faster on
64 bit:
unsigned long array[ARR_SIZE];
for (i = 0; i < ARR_SIZE; i++) {
array[i] ^= (unsigned long)SOME_CONSTANT;
}
However, the two previous replies seem to suggest that there should be no
performance
advantage to running 64 bit applications. So which of these options is true:
1. There may be a performance advantage to running 64 bit code, but
applications are not
tuned to exploit it; or
2. There is no performance advantage (under SPARC) in running 64 bit code.
Thanks,
--Elad
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
