Ubuntu 16.04 LTS 32-bit vs. 64-bit Linux Performance

[phoronix]

Phoronix: Ubuntu 16.04 LTS 32-bit vs. 64-bit Linux Performance

Every year or two we run >32-bit vs. 64-bit Linux benchmarks. While x86_64 Intel/AMD hardware has been extremely common for quite some time, we continue to be amazed at the number of people still running an i686 Linux distribution on x86_64 hardware.

http://www.phoronix.com/vr.php?view=22917

[Kemosabe]

Where does the performance gain come from?

[rob11311]

AMD64 specified more registers and function parameter passing using those, so basically less memory references which can stall
Floating point can also assume SSE2 at least, rather than the old 387 style FP unit compatible 80bit floats.

Code which has lots of pointers may run slower, especially if it exceeds L1 cache, because of the doubling of memory address sizes.

[M@yeulC]

My laptop is still 32 bits only, though, so I am glad distributions still support 32 bits.
And I think it will stay that way for a bit more time, since there is still proprietary software that is 32bits only.

[anarki2]

My laptop is still 32 bits only, though, so I am glad distributions still support 32 bits.
And I think it will stay that way for a bit more time, since there is still proprietary software that is 32bits only.

You can run 32 bit software on 64 bit Linux, you know.

[schmidtbag]

Where does the performance gain come from?

That's kind of like asking why a shovel picks up more sand than a spoon.

[Kemosabe]

That's kind of like asking why a shovel picks up more sand than a spoon.

Are you proud of your answer?

[bpetty]

AMD64 specified more registers and function parameter passing using those, so basically less memory references which can stall

I've always wondered how FreeBSD performs so well when they push almost everything to the stack instead of registers. I would think that must be a serious performance penalty, but should help significantly with porting.

[milkylainen]

I've always wondered how FreeBSD performs so well when they push almost everything to the stack instead of registers. I would think that must be a serious performance penalty, but should help significantly with porting.

On modern x86 CPU's you can call the x86 ISA a frontend. So what the CPU does and how it stores data has some but not total resemblance to actual code layout/structure/preference. Most modern CPU's have a CISC/RISC frontend and post-RISC macroop/fusioning backend. Only decode flow and writeback really guarantees normal ISA behavior. The rest is a black box.
So I would not be surprised if you can get decent performance out of stack operations instead of register ops on modern CPU's.

[Delgarde]

Where does the performance gain come from?

The simplified version - because your 32-bit x86 binaries are built to run on a 32-bit x86 CPU. A 64-bit x86_64 CPU is essentially a superset of the x86, but if your code isn't compiled for that superset, it's not going to use any of it. Mostly, that means x86 binaries can't take advantage of extra registers added by x86_64, and so must waste more time copying data to and from RAM.

As a note, there *is* an architecture called x32 which remains 32-bit, but is designed to run on x86_64 hardware. An x32 binary would have much the same performance as x86_64 - possibly a little better in theory, since keeping things 32-bit is a little more efficient in terms of memory use. It's never really caught on, though, because that slim advantage in efficiency doesn't really outweigh the inconvenience of maintaining an extra architecture.