Originally Posted by selfprogrammed
Running 64 bit mode requires 50% to 100% more memory because of the larger pointers and default integers
Pointers are twice as big in 64-bit mode, but default integers are still 32-bit in 64-bit mode. The size of floating point numbers is also not affected by 32 vs 64 bit architecture.
Very few programs have pointers as such a large fraction of their data that they could take even 50%, much less 100% more memory.
Some programs have pointers as a much larger fraction of their memory accesses than of their memory use. On early or cheap 64-bit CPUs with low L2 cache size, such programs might run around 20% slower in 64-bit mode because of the increased L2 cache misses. For many such programs, that problem goes away on CPUs with larger L2 cache.
64 bit execution is marginally faster for programs with large numbers (because can use single instruction),
Programs getting a significant performance boost from that difference are so rare, they are statistically nonexistent.
The big boost from 64-bit mode happens because 64-bit has twice as many registers. GCC is especially bad (compared to other compilers) at dealing with the register shortage in 32-bit x86 architecture. Most Linux users use almost exclusively code compiled by gcc, so that magnifies the advantage of 64-bit.
Also, 32-bit compilers typically emit code using x86 legacy floating point, even though most 32-bit CPUs have newer floating point. 64-bit CPUs all have newer floating point, so the compilers all use it.
1) Most programs are limited by factors other than CPU speed, so no speed difference between 32-bit and 64-bit mode.
2) Few programs use pointers so heavily that on a CPU with small L2 cache, 32-bit mode will run significantly faster.
3) For the remainder, 64 bit is generally faster and may be significantly faster, especially for operations like transcoding video or audio.