User: Password:
|
|
Subscribe / Log in / New account

Some Thoughts on the Current State of 64-bit Computing

Some Thoughts on the Current State of 64-bit Computing

Posted Feb 17, 2005 15:41 UTC (Thu) by Duncan (guest, #6647)
In reply to: Some Thoughts on the Current State of 64-bit Computing by Kluge
Parent article: Some Thoughts on the Current State of 64-bit Computing

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


(Log in to post comments)

Some Thoughts on the Current State of 64-bit Computing

Posted Feb 17, 2005 16:40 UTC (Thu) by elanthis (guest, #6227) [Link]

"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?"

Fortunately, it doesn't matter if you compile for i386 or not, because almost every piece of software that needs SSE or the like does the detection at *run-time*. Simply compiling for a newer version of an architecture isn't going to make your apps run any faster; heck, depending on exactly what the app does and which compiler you use, it might even end up slower. You can't automatically turn some random bit of code into an SSE-using speed demon.

For the few apps and libs were the recompilation *can* make a difference, at least some "lowest common denominator" distros provide multiple architectures of those packages, Debian and Fedora included.

Fedora and optimisation Current State of 64-bit Computing

Posted Feb 18, 2005 3:01 UTC (Fri) by gdt (subscriber, #6284) [Link]

Although FC3 contains "i386" packages which only use 80386 instructions the choice and order of those instructions is optimised for the Pentium 4.

The problem with the tactic of providing i686 versions of packages is that the demonimation no longer discriminates between the processor classes of interest: Pentium II, Pentium III/Pentium M and Pentium 4.

The tactic also fails for machines with a targetted use. It might be acceptable not to get the utmost out of Apache or Samba when they are used on a desktop, but it is not so acceptable when Apache is used as a web server or Samba is used as a file server.

Some Thoughts on theCurrent State of 64-bit Computing

Posted Feb 18, 2005 7:36 UTC (Fri) by nix (subscriber, #2304) [Link]

You can't automatically turn some random bit of code into an SSE-using speed demon.
-mfpmath=sse? :)

(Of course, this breaks the i386 ABI, so is really an argument in favour of your point...)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds