Re: Performance difference 32bit/64bit userland
In enterprise world, Java applications will benefit from 64-bit addressing.
Another example is Oracle, 32-bit server side is dropped while ago. So
it also make sense to compile all Oracle client linked apps with 64-bit
compiler. Might be offtopic, but all above is true also for AIX. Most
binaries are 32-bit.
On 2017.02.07. 19:34, Lennart Sorensen wrote:
On Tue, Feb 07, 2017 at 06:21:42PM +0100, Christoph Biedl wrote:
while preparing other tests I created two installations on two hosts
with identical hardware (LPARs on IBM POWER):
- powerpc (64 bit kernel, 32 bit userland)
- ppc64 (64 bit kernel, 64 bit userland)
Both are up-to-date sid with systemd held to 232-10 (#852811).
Now the surprise: Using the 32 bit userland, CPU bound operations like
gzip or xz are significantly faster (5 to 10 percent). Comparing to x86
where i386 is 10 to 15 percent slower than amd64. Also running
debootstrap showed a similar pattern. All tests were repeated a few
times to rule out any caching or similar effects.
This is not quite satisfying. Anyone an explanation for this?
64 bit pointers take twice the cache space (and memory bandwidth) of 32
bit pointers. There is essentially not other difference between 32 and
64 bit powerpc.
x86 is different. AMD did a nice job fixing a lot of mistakes in x86
as part of designing the 64 bit version of x86. The big changes are to
double the number of registers, since the x86 has always been terribly
register starved. This alone accounts for most of the performance
improvements you see on 64 bit x86. Of course as a result x32 ought to
actually be slightly faster since it uses the instructions and registers
of x86_64 while using only 32 bit pointers. Smaller pointers mean less
cache usage making room for more stuff to actually be cached and less
memory bandwidth used to move the pointers around in the first place.
Dropping support for x87 FPU instructions and mandating SSE instead is
another huge improvement in x86_64 over x86 although some systems were
already doing sse floating pointer with 32 bit builds if they were
specificly compiled for new 32 bit x86 chips, although I think that
would mean P3 and P4 only.
Most architectures other than x86 loose a bit of speed in 64 bit mode
compared to 32 bit mode unless they make other architectural improvements
at the same time (as x86 did). In some cases those changes were big
enough to justify a 32 bit mode using those enhancements (as x32 does
for x86 and mips n32 does for mips) to get all the advantages without
the 64 bit pointer size disadvantage.
You really have no need for 64 bit pointers except for programs that
need to use more than 2 or 3 GB of memory space. For everything else,
32 bit pointers are better.
So yes this is normal and expected.