Re: Fujitsu Siemens Primepower
Daniel Rock <abuse@xxxxxxxxxxx> wrote:
....
> clock speed than UltraSPARC-III. In contrast to US-III a program compiled
> as 64 bit runs at roughly the same speed than the same program compiled as
> 64 bit. On US-III I have seen performance drops when moving from 32 bit to
> 64 bit from 5-30%[1].
>
> [1] programs which don't need large address space but could benefit from
> native 64bit "long"s (resp. "long long"s)
Empirically speaking,
code that's heavy with 64bit integer computation compiled with -xarch=v9
(64bit ABI) doesn't run any faster than the one compiled with -xarch=v8plus
(32bit ABI with 64 bit instructions),
because with v8plus, compiler already uses *all* 64bit instructions available.
The only difference between v9 and v8plus are:
1) the address space is limited to 32bit
2) there are less number of 64bit integer registers (32 vs 16) available..
1) helps performance on 32bit
because pointers are all 4-bytes,
hence all datastructure sizes are smaller,
so less space in the cache and thus more stuff can fit in the cache.
This effect is a bit more pronounced on US3 than on SPARC64
because SPARC64 are out-of-order (vs US3 being in-order issue)
and generally has bigger caches.
2) hardly makes difference in most integer code
because they tend not to require that many registers
and even when they do, they run out of registers
because of pointers and offsets, not because of 64 bit integers).
Overall, on SPARC, there's very few compelling reasons to use 64bit.
Beside 64bit address space, the only other thing
I can think of is the user trap handling (man __sparc_utrap_install).
--
#pragma ident "Seongbae Park, compiler, http://blogs.sun.com/seongbae/";
.
