Some Thoughts on the Current State of 64-bit Computing

Posted Feb 17, 2005 15:41 UTC (Thu) by Duncan (guest, #6647) [Link]

Yes, the speed difference can be and often is "significant". Your
understanding on both counts is correct.

64-bit values taking up more space (and bandwidth, don't forget memory and
disk bandwidth) combined with the fact that 32-bits is "big enough" for
many tasks, weighs toward the 32-bit side, as does compatibility with
slaveryware as well as not-yet-ported freedomware.

OTOH, weighed toward the 64-bit side are a number of factors as well. You
mentioned the register thing. x86 as an arch has been considered a poor
32-bit implementation for many years, because of the relative scarcity of
full CPU speed (no look-up time lost direct assembly language reference)
registers. AMD64/x86_64 is far more competitive with other 64-bit archs
in this regard.

However, likely one of the biggest performance positives for AMD64 is
often overlooked entirely. Because it's a new platform at its "base"
level in terms of CPU instruction sets, unlike x86
(386/486/686/mmx/sse/sse2/etc) applications precompiled for the platform
are generally decently optimized for it. This applies equally well to
freedomware but normally binary distributions, and
slaveryware*/proprietaryware from the likes of MS. How many people are
running x86 binary platforms (libre or not) optimized for the lowest
common denominator, i386, i586, i686 if one is lucky, because it's not so
practical to deliver all those options and more (latest SSE optimized,
etc) in a multitude of binary packages? With AMD64, it's early enough in
the history of the platform that simply being compiled for AMD64/x86_64
means there's a closer match between the capacities of the hardware, and
what the software is compiled to take advantage of, yet by now late enough
that at least for those packages compiled with gcc 3.4 and later, there's
significant native optimization for the platform. No more running i386 or
i586 rpms because that's what's the distrib has chosen as its lowest
common reference platform target!

(Of course, I should note that I'm running Gentoo and compile everything
from source with my own choice of optimizations, so the above binary
advantage doesn't apply here. However, I switched from Mandrake, which
used i586, and found RH's i386 targeting even more curious -- well over a
decade after the chip became obsolete. Yes, I'm aware of Debian and in
fact would have probably switched to it if Gentoo hadn't been available,
but I haven't the foggiest what their 32-bit binaries target, so I had to
stick with rpms in the above.)

Of course, the flatter memory implementation of 64-bit tends to
decomplicate things as well, and that will become an ever greater issue as
>= 1GB desktop memory becomes ever more common, but that doesn't become a
HUGE issue until >4GB, which is still some time off for most desktop use,
anyway.

I'd certainly recommend going 64-bit with the software as well, for most
folks wishing to stick to freedomware. For those willing to compromise
their freedom in the interest of pragmatism, it really depends on what
apps they regularly use. If most of them are 64-bit, going 64-bit will
likely be the better option. Those running particular 32-bit
applications, or those targetting widest 32-bit compatibility in general,
however, as would be the case for heavy slaveware game players who've
chosen to let the game authors be their master and choose their platform
for them, will unsurprisingly find that running their AMD64s as 32-bit
processors is naturally the closest compatibility possible, since in that
case, for the software anyway, it really /is/ 32-bit, not just 32-bit
compatible.

.....
* Slaveryware: A reference to the quote I have as my USENET sig:
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_...

I found the first page of that interview very thought provoking, even
where I didn't agree with it. Obviously, however, I agree with the above
strongly enough to have adopted the terminology for my own.

Duncan