On Wednesday, October 24, 2012 7:46:39 PM UTC+2, Patrick Mylund Nielsen wrote:
I'm not trying to dispute that x64 is faster than x86. That would be silly.
It depends on the machine used by the developers of the software. If they
are mostly using 32-bit x86 machines the developers will make optimization
choices that work for 32-bit x86 while ignoring the consequences of source
code modifications on 64-bit x86. The overall process seems similar tohttp://en.wikipedia.org/wiki/Supervised_learning
in AI. Developers are
optimizing based on measured data, so if there are measurements for 32-bit
and no measurements for 64-bit then it may happen that the software will
run faster on 32-bit machines.
Advantages of x86-64 over x86-32 are not clear (not mentioning the obvious
fact that 64-bit pointers consume two times the memory of 32-bit pointers):
- accessing the 8 additional registers on x86-64 requires a prefix in the
- instructions working with 32-bit integers differ from 64-bit versions
because of a prefix in one form of the instruction
In general, x86-64 isn't an uniform extension of x86-32 (it is a
non-uniform extension). An ideal uniform extension would, for example,
mandate two instruction decoders in the 32+64-bit CPU (and consequently a
slightly redesigned instruction encoding in 64-bit mode). That said, x86-64
is very close to being a uniform extension of x86-32.
Today there do not exist purely 32-bit versions of x86 CPUs (with no 64-bit
mode in the silicon) that would have a corresponding 32+64-bit version, so
it is hard to tell whether CPUs without any 64-bit mode would be faster
thanks to a slightly higher operating frequency.
I believe that a 32-bit address space is already large enough for almost
any application in the sense that extending the address space to 64 bits
does not improve the application's performance in any way. This requires
programs working with large datasets to swap data to/from the disk at
run-time, or alternatively to use some form of data compression. x86 has no
architectural support for this programming style. Go as a safe
programming language (without cgo) seems compatible with this programming
style because it appears possible for a Go implementation to do the
swapping and compression automatically.
All I said was that the memory overhead is usually larger.
Companies like Canonical still refer to their 32-bit edition of Ubuntu as
the recommended download, and Linode strongly recommends everyone to use
the 32-bit distributions (in the latter case, specifically because of the
decrease in memory usage.)