Your editor did much of his early programming on a large, 60-bit computer.
"Large" as in "you could walk around inside it." Its six-bit character
set was challenged by exotic characters - like lower case. But it sure had
a fast card reader. Your editor has started a few articles by saying that
recent "progress" has made things worse, rather than better, but he won't
be saying that this time.
By the early 1980's, 32-bit systems had taken over much of the computing
world. And, with certain exceptions, 32 bits has been the way of things
for a good two decades. Processor speeds have gone up by three orders of
magnitude, as have disk sizes; main memory has grown by even a bit more.
But most systems sold today still use 32-bit words and addresses. The fact
is, 32 bits suffice for almost every quantity we need to manipulate with
computers. The exception, increasingly, is memory. We have hit the point
where we are running out of address space. The need to work with ever more
memory to run our increasingly bloated applications will eventually push
much of the industry over to 64-bit processors.
Your editor decided to be ahead of the curve, for once. So he ordered up a
new motherboard and Athlon64 processor. Before the process was done, he
also ended up buying a new video card, power supply, and disk drive. In
fact, the only original component left in the case (a holdover from when LWN
thought it might be a training company) is the diskette drive. But, the
new system is now up and running, and your editor has had a chance to get a
feel for what the 64-bit world has to offer.
The hardest question, perhaps, was the choice of distribution to run. The
new system replaces a Debian unstable box, so Debian was the obvious first
choice. The state of the Debian x86_64 port is a
little discouraging, however. Installation requires starting with the
basic x86 distribution, coming up with 64-bit versions of gcc and glibc,
building a new 64-bit kernel, booting that, and piecing together the rest
of the system with the other x86_64 packages that have become available.
More than ten years ago, your editor converted, by hand, his first Linux
box from a.out to ELF binaries; installing Debian x86_64 looks like a
similar process. Somehow, what looked like an interesting and instructive
adventure in the early 1990's is distinctly less appealing now.
MandrakeSoft and SUSE both offer x86_64 versions of their distributions. The
Gentoo port seems to be coming along reasonably well, but some time spent
digging through the Gentoo package
database shows that much of the software base still lacks x86_64 support. Your editor,
in the end, went with the Fedora Core 2 test 2 release, at least for
now. FC2t2 gives good visibility into the development process (as do
Mandrake and Gentoo), a familiar, Red Hat core, and the ability to play
around with some bleeding-edge features like SELinux. It also is designed
around the 2.6 kernel, which is an important feature.
When one leaves the x86 mainstream, it does not take long to realize that
the well-trodden pathways have been left behind. Mirrors for the x86_64
architecture are relatively scarce and often behind the times. Most
applications do not, yet, come prebuilt for this architecture.
Documentation on how to get x86_64 systems up and running is minimal. It
is all a bit of an adventure.
That said, the FC2t2 distribution works well - as well as could be expected
on any architecture for a development release. And the really nice thing
about the x86_64 architecture is that most 32-bit x86 binaries work just fine,
as long as you have 32-bit versions of the relevant libraries around. That
fact alone makes the transition to this architecture relatively easy.
The need for 32-bit libraries complicates system administration, however.
An x86_64 Fedora system has many duplicated packages installed, and working
with rpm can, occasionally, be a bit confusing. The rpm interface was not,
perhaps, designed for dealing with a world where two packages have the same
name and version number, but are still distinct. Unless you plan to leave
the 32-bit world behind entirely, however, you will need two versions of
the libraries. Chances are that most x86_64 systems will want to run
32-bit binaries for some time - in some cases, they perform better, and, in
any case, some programs in FC2t2 (e.g. OpenOffice.org) are still built that
Building applications can also be a bit of a challenge, at least a first.
Quite a few makefiles and configure scripts assume that libraries live in
/usr/lib. On a Fedora system, /usr/lib has the 32-bit
versions of the libraries; the native versions live in
/usr/lib64. A makefile which uses the default gcc (which compiles
in 64-bit mode) and tries to explicitly link against things in
/usr/lib will fail. Once you learn to recognize this problem, it
gets easy to fix.
Your editor was naturally interested in performance issues. To that end,
he built a version of bzip2 in both 64-bit and 32-bit mode and compared the
results. Both compression and decompression ran about 10% faster in the
64-bit mode. With the x86_64 processor, better performance is generally expected in
the native mode, mainly due to the additional registers which
are available. The executable size and memory usage in 64-bit mode were
larger, but not by much. A second test, using the SoundTouch
library yielded a surprise, however: changing the tempo of a large sound
file ran in less than 1/5 the time in 32-bit mode. The Athlon64 processor,
it would seem, runs certain operations far more slowly in 64-bit mode; your
editor has not, yet, had the time to track this one down.
Despite the paucity of mirrors, the glitches, and the surprises, the x86_64
platform makes for a very nice Linux system. The kernel support for this
architecture is outstanding, the performance is good, and the expanded
address space renders concepts like "high memory" obsolete. After all,
we'll never need more memory than can be addressed with 64 bits...
Seriously, however, this architecture has helped to realize one of the
great promises of Linux: a freedom of choice in hardware as well as
software. 64-bit systems are now available at a price even an LWN editor
can afford. This editor, who just shifted his old Pentium 450 box over to
sacrificial kernel testing duty, is distinctly less grumpy.
to post comments)