OSNews

By simply recompiling the software as 64-bit (assuming it's compiled rather than assembly code) then the compiler will make use of the extra registers when optimizing and thus generate (generally) faster code.

In short, it doesn't have to be written directly for 64-bit, although some of the best improvements between 32-bit and 64-bit I've seen are with hand written assembly. For instance I recall x264 can do something like ~35% faster encodes when using 64-bit while using more demanding presets.


Depending on what you mean by 'automatically', if they are compiled as 64-bit, then yes. You can do this explicitly by adding -m64 to GCC when compiling.


Well os'es are written to be extremely low-latency so optimizations which makes a user-detectable difference are most likely algorithmical rather than the result of compiler optimizations. In short, the OS code will run faster by using these extra registers but you are very unlikely to notice it.

However, when we come to user apps, many of which are not low latency but rely on pure throughput, like compressors, video/audio encoders (like the above mentioned x264), renderers, etc, then the typically ~10-20% improvement in performance with x64 can be a nice boon.

There is one downside to 64bit though, and that is that the code size gets larger (iirc around ~15-20%) which is due to the pointers increasing from 32-bit to 64-bit. This in turn makes 64-bit less efficient performance-wise than it could have been given that the increased code size means it will fill up the cpu caches faster which is also the reason that 32-bit code sometimes (very rarely) can beat equivalent 64-bit code in performance.

There's a new ABI for Linux (x32) which removes this downside by using 32-bit pointers (and thus smaller code) while still using the extended register set in x64 and has shown benchmarks of being ~15% faster than x64-bit code. However using 32-bit pointers means x32 still suffers from the same 4gb addressable ram limit per process like standard 32-bit code does. However if you are fine with your apps only being able to use 4gb (per process, not systemwide) then x32 should be the best of both worlds as far as performance goes.

32-bit needs to be built with older systems in mind, ie. those without SSE (any version). On an x86-64 computer, the system can assume these extensions are available (and thus use them in the base system and ABI).

This is especially true on Haiku, since it's compiled for i586, which means but it'll run on a Pentium Pro, but precludes using SSE2 or later in binaries.