Linux was created on the first 32-bit CPU in the x86 CPU family, the 80386. But the days of 32-bit computing are coming to an end. Luckily, the AMD64 provides compatibility features that ease the transition. Here's a hands-on guide to building and benchmarking a 64-bit Linux desktop based on AMD64.
Linux was created on the first 32-bit CPU in the x86 CPU family, the 80386. Since then, computing has evolved substantially, and while 32-bit computing remains adequate for many purposes, its days are nearing an end. Increasing demand for RAM will soon dictate a shift to 64-bit architectures.
Fortunately, 64-bit CPUs are currently available and are beginning to move into the mainstream. One of these architectures, AMD’s AMD64, is gaining in popularity, and seems likely to dominate the market currently held by its Intel Architecture-32 (IA-32, or x86) predecessor.
Shifting to a new CPU architecture may seem intimidating, but AMD64 provides compatibility features that ease the transition. Linux’s open source code helps too: because source code is available and can be recompiled relatively easily, Linux distributions for AMD64 are already stable.
When comparing IA-32 to AMD64, 32-bit and 64-bit refer primarily to the size of the CPUs’ data registers, including both the general-purpose registers and the address registers. A 32-bit register is capable of storing a value up to 232, or about four billion, while a 64-bit register can store values of up to 264, or about 1.8×1019. Fundamentally, a 64-bit CPU is just one that can work on larger numbers.
While most common applications, such as word processors, web browsers, and mail servers, don’t often need to work with integers larger than four billion, a few specialized applications do. Encryption software frequently uses keys that are quite large, and Linux’s JFS and XFS also use 64-bit pointers to implement very large filesystems. For those applications that make heavy use of 64-bit arithmetic, 32-bit CPUs must do extra work to manipulate the 64-bit or larger numbers using only 32-bit registers. That’s inefficient. But running on a 64-bit CPU provides a substantial speed boost.
The maximum size of physical memory is also limited by 32-bit registers. Because IA-32 memory addresses are stored as 32-bit numbers, IA-32 CPUs can only address up to 4 GB of memory. Going beyond that limit on an IA-32 requires ugly bank switching, in which parts of memory are temporarily “hidden” from the CPU while other parts are accessed. This technique was heavily used by pre-80386 CPUs, and was uniformly despised by programmers of the day. AMD64 processors, on the other hand, can address up to one terabyte of physical memory and 256 terabytes of virtual memory.
A final benefit of 64-bit computing is unique to the AMD64. This CPU — which has also been called x86-64 and is currently sold by AMD as the Athlon 64, Athlon 64 FX, and Opteron — is essentially a 64-bit extension of the IA-32. In creating its 64-bit mode, AMD revisited and reworked some of the IA-32 design decisions that have hindered IA-32′s speed. Most importantly, AMD doubled the number of registers on the CPU, as well as doubling their size. Because storing data in registers is much faster than storing data in RAM, increasing the number of registers has the potential to enhance the speed of programs that are simply recompiled for the new platform. So, although the shift from a 32-bit to a 64-bit CPU does not in itself improve program speed, the shift from IA-32 to AMD64 does. As a practical matter, if you buy an AMD64 CPU, you’ll get better performance from the system if you run a 64-bit operating system and 64-bit applications than if you run a 32-bit OS and 32-bit applications.
Intel’s and AMD’s 64-bit Contestants
Lurking just behind AMD is Intel, the company that’s dominated the desktop CPU market for two decades. Intel’s initial 64-bit variant of the IA-32 platform, the IA-64, is sold as Itanium. Although Itanium can run older IA-32 code, it can only do so from a 32-bit operating system, and the speed penalty for running 32-bit code is substantial.
AMD, by contrast, decided to extend IA-32 in a more compatible manner. The result is that the AMD64 can run 32-bit programs alongside 64-bit programs, much as current IA-32s can run 16-bit programs alongside 32-bit code. Unlike Intel, AMD has chosen to market a wider range of 64-bit CPUs, and has targeted some of them (namely, the Athlon 64 line) at high-end desktop users.
Furthermore, because the speed penalty for running 32-bit code is lower for the AMD64 architecture than for the IA-64 architecture, AMD64 makes a safer migration path: you can buy an AMD64 system and run your 32-bit OS on it if the 64-bit OS doesn’t work out, with little in the way of speed penalty.
AMD’s design decisions and marketing strategy appear to be paying off, with strong sales in the first few months of AMD64′s life. At the same time, Intel’s Itanium has remained expensive and unpopular. In fact, a recent announcement by Intel appears likely to guarantee the AMD64 platform a place on most desktops in the near future: Intel will produce AMD64 CPUs!
To be sure, Intel is downplaying the fact that they’re following in AMD’s footsteps, calling “their” new architecture IA-32 with 64-bit Extensions or Extended Memory 64 Technology (EM64T). No matter the name, EM64T really is the same architecture as AMD64 — mostly. Intel is adding a few features not found in AMD’s CPUs, but Intel’s AMD64 processors should run the same binaries as AMD’s AMD64 chips. The situation appears likely to evolve into one akin to the current 32-bit market, with its Pentiums, Athlons, Celerons, and Durons: to get the very best performance from a CPU, you may need to set specific compiler options, but they’ll all run generic code reasonably well.
The development code names for the new Intel CPUs are Nocona and Potomac, and it appears they’ll be sold under the Xeon line. (Yet another proposed name for the CPUs is Clackamas.) Intel has also announced that they’ll extend the Prescott (Pentium 4) core with 64-bit extensions, so it seems likely that Intel will eventually release AMD64 CPUs targeted at the desktop market. Intel plans to release the first of these CPUs in the second half of 2004, but the precise date is still unknown.
Be the First On Your Block!
If you want to get into AMD64 computing today, an AMD-branded CPU is your only choice. As this issue of Linux Magazine goes to press, Athlon 64, Opteron, and Athlon 64FX CPUs are all available.
The Athlon 64 is an entry-level model that requires a Socket 754 motherboard (upcoming models will require a Socket 939 motherboard). Athlon 64 models include the 2800+, 3000+, 3200+, and 3400+, which are named to simplify speed comparisons with Pentium 4 CPUs. For example, the Athlon 64 3200+ is roughly equivalent in speed (when running 32-bit code) to a 3.2 GHz Pentium 4.
Opteron CPUs are intended for server use and have model names of the form 1xx, 2xx, and 8xx, where xx is a two-digit number. The first digit (a 1, 2, or 8) denotes the maximum number of CPUs you can tie together in a multi-processor system.
The Athlon 64FX is virtually identical to an Opteron 1xx-series CPU, but is marketed for workstation use. Both the Opteron and the Athlon 64FX use Socket 940 motherboards.
If you set out to buy an AMD64 system, be sure to investigate motherboard chipset compatibility with Linux. As of the 2.6.4 kernel, the nVidia nForce3 150 and VIA K8T800/ VT8237 are both well-supported, although audio glitches plague the VIA’s built-in sound hardware. The SiS 755/964 works with Linux, but Serial ATA (SATA) hard disk support is poor and audio support is uncertain. So far, no information is available on ALi M1687/M1563 Linux compatibility.
Also, be aware that manufacturers often supplement or replace chipset features with additional support chips. For instance, the current crop of Athlon 64 chipsets doesn’t support Gigabit Ethernet, so any board that provides that feature uses a separate Gigabit Ethernet chipset. (The next generation of Athlon 64 chipsets will probably support Gigabit Ethernet natively, and at press time, nVidia was just releasing their next AMD64 chipsets.)
To develop this article, a (fairly) low-end Athlon 64 test system was constructed from the following components:
* A Microstar International (MSI) K8T Neo-FSR motherboard (which uses a VIA K8T800/VT8237 chipset and a Realtek 8110S Gigabit Ethernet chip).
* An Athlon 64 3000+ CPU
* 512 MB of Buffalo-brand ECC DDR400 RAM
* A generic SiS Xaber 200 (aka SiS 330) video card
* An Antec True 430 power supply
* The usual extras, such as a CD-ROM drive, a floppy disk, a case, and so on.
The total cost of the test system was $650, but a few parts (including the monitor, keyboard, mouse, and CD-ROM drive) were scavenged from older computers. As a comparison, putting together a system based on a 3 GHz Pentium 4 would have cost about $50 less, and a system based on a 32-bit Athlon XP 3000+ would have cost about $150 less. Pre-assembled Athlon 64 systems can be found in stores for (barely) under $1,000.
Penguin 64 Options
You can run a 32-bit Linux distribution on an AMD64 CPU, of course, but there’s nothing extraordinary about that — you can also run DOS, Windows, or other 16- or 32-bit operating systems on these new CPUs. The great benefit of Linux is that it’s relatively easy to recompile the kernel and most Linux applications for the new CPU’s native 64-bit mode.
To date, six major Linux distributions are available for AMD64: Fedora Core 1, Gentoo 2004.0, Mandrake 9.2, Red Hat Enterprise Linux AS, SuSE 9.0, and TurboLinux 8. Of these, Fedora, Gentoo, Mandrake, and SuSE were tested for this article. A beta version of SuSE 9.1 was also briefly tested. It’s likely that by the time you read this, newer versions of each distro will be available.
Fedora, Gentoo, Mandrake, and SuSE installed without a hitch, although SuSE 9.0 couldn’t see an SATA hard drive, and had to be installed onto an older, parallel ATA (PATA) drive. (SuSE 9.1 had no problem with the SATA drive.) Fedora and Mandrake both had problems with the SiS Xaber video card, but that problem was solved by copying the sis_drv.o XFree86 driver file from the Gentoo installation. Many Mandrake executables, including NEdit, gedit, and gFTP, crashed with segmentation faults, rendering the distribution difficult to use.
Overall, Fedora and Gentoo seemed the most robust of the 64-bit distributions. SuSE 9.0 exhibited a few more minor problems, but overall, was better than Mandrake. The SuSE 9.1 beta seemed to be a slight improvement on the 9.0 release, and it’s likely that the final SuSE 9.1 will be quite useable on the platform.
As on the x86 platform, Fedora is a good general-purpose distribution. Gentoo’s focus is on extreme configurability, which requires you to have greater knowledge of your system. On the other hand, Gentoo’s package approach means you can keep up to date with it very well, and that’s important in the fast-changing AMD64 world.
Installing an AMD64 Linux distribution is much like installing an x86 distribution. The AMD64 BIOSs are very similar to their IA-32 counterparts, and the boot process is identical from a user’s point of view. Both platforms use the standard IA-32 partition table, so you prepare your hard disks just as you would for a 32-bit OS. You can even install a 64-bit distribution alongside a 32-bit distribution. The two can read each others’ filesystems, so you can share a /home directory and even swap partitions. (JFS appears to be a risky filesystem on AMD64, though.) The version of GRUB that ships with IA-32 distributions has problems loading a 64-bit kernel, so you should plan to use the AMD64 distribution’s GRUB.
Most Linux programs have already been recompiled for AMD64, and ship in 64-bit binary form with the binary-based distributions. When you run bash, XFree86, or KMail, you’ll be running native 64-bit code. A few programs either don’t yet compile properly in 64-bit form or aren’t yet available (commercial programs, for instance). For the benefit of such programs, all of the major AMD64 distributions provide 32-bit compatibility libraries. These consist of 32-bit executable support in the kernel and a set of 32-bit libraries that 32-bit programs can call. (The 32-bit programs can’t call 64-bit libraries.)
Fedora, Mandrake, and SuSE all provide compatibility libraries, and the libraries reside in the same directories as the IA-32 versions of their distributions. This way, you can install an RPM from a 32-bit distribution directly on your system. If the RPM includes libraries, they go in an appropriate directory and won’t interfere with like-named 64-bit libraries, which reside in their own 64-bit directories (such as /lib64/).
Gentoo works a bit differently: It gives the stock library locations to 64-bit libraries and places 32-bit libraries in a special directory tree called /emul/linux/x86/. As Gentoo doesn’t rely much on binary packages, compatibility with 32-bit packages is less of an issue, but if you do need to install a 32-bit binary, you’ll need to carefully extract it to avoid overwriting any 64-bit libraries.
Computing at 64-Bit Speed
One of the benefits of being a Linux user and an early adopter of AMD64 is that you can squeeze a little extra speed out of the hardware — something that Windows users can’t yet do, at least not with released versions of that operating system. Just how much of a benefit is there to 64-bit code, though?
To find out, nbench (http://www.tux.org/~mayer/linux/bmark.html) was compiled using gcc 3.3.2 under both 32- and 64-bit versions of Fedora on the same hardware. nbench tests raw memory, CPU, and FPU performance with minimal contamination from the host OS. After a reboot and without X running, the benchmark yielded the results shown in Table One.
Table One: nbench benchmark results (higher values are better)
As you can see, the change to 64-bit was quite modest for memory and floating-point performance. This is to be expected: the AMD64′s 64-bit mode doesn’t affect how memory is accessed, aside from enabling a larger memory footprint, and AMD didn’t change the floating-point architecture of the CPU. The big difference in these benchmarks comes in the integer performance, in which the 64-bit code performed almost 35 percent better.
Of course, nbench is a somewhat artificial benchmark program. In real-world applications, other factors may overwhelm the CPU’s integer performance.
To benchmark further, the test machine decompressed and compressed files using gzip and bzip2, created Ogg Vorbis files, PGP-signed a large file (using gpg), and configured and compiled a program (NcFTP). Table Two shows the results. (All tests were run after fresh boots of each OS, using the same files on the same partition, and after all temporary files were removed.) Since Table Two presents results in seconds, lower values are better.
Table Two: Real-world performance times (in seconds)
Arguably, the compilation test isn’t fair, as the compiler’s output is different for the two conditions. As a real-world test, though, it seems logical, as you’re most likely to be compiling a program for the platform you’re using.
Clearly, 64-bit code on an AMD64 gives you a noticeable speed boost, at least for certain operations. The greatest benefits accrued to Ogg Vorbis encoding and PGP signing. 64-bit mode offered only trivial benefits for compiling the test program, though, perhaps because these tasks involve substantial disk access.
In evaluating these results, you should remember that these tasks are CPU-intensive. Switching to AMD64 code won’t improve your disk performance or the performance of programs that mainly move data in and out of memory. Still, the effect is noticeable. In very rough terms, an Athlon 64 3000+ running 64-bit code might match or beat an Athlon 64 3400+ running 32-bit code.
Hurdles to Overcome
The 64-bit future heralded by the AMD64 is not without its challenges. Fortunately, most of the problems that exist in today’s AMD64 implementations will be overcome in time, because they can largely be attributed to legacy 32-bit applications. A few problems, though, concern 64-bit programs.
Most open source software for Unix and Linux is written in a way that’s 64-bit friendly, thanks to the history of earlier 64-bit CPUs, such as the DEC Alpha and Sun Sparc. If a program compiles and runs on a wide variety of CPUs, including earlier 64-bit models, chances are it will work perfectly well on an AMD64 CPU.
Sometimes, though, this isn’t the case. For instance, the popular OpenOffice.org office suite doesn’t yet compile in native 64-bit mode. (Historically, this package has been supported on a narrow range of platforms, so it still contains some CPU-specific code.) Similarly, WINE won’t compile in 64-bit mode, but as WINE is a compatibility layer for running 32-bit Windows applications, it’s not clear just how much benefit a 64-bit version of WINE would provide.
Some programs simply aren’t available in 64-bit versions, and some may never be. For example, the chances of you ever obtaining an old commercial program such as WordPerfect 8 for Linux in 64-bit form are nil.
You may also run into occasional incompatibilities and quirks. As already noted, several Mandrake programs crashed in 64-bit mode.
One great benefit of the AMD64 architecture is that when you run into a problem with 64-bit code, you can try a 32-bit version of the same program. Frequently, this solves the problem, although it is an inelegant solution in some ways — you must maintain legacy 32-bit libraries, and the 32-bit program will probably run slightly slower than a native 64-bit version would, if it were available. Examples of 32-bit programs that run under AMD64 emulation on all of the platforms tested include:
* WINE. To test WINE, the software was compiled under the 32-bit version of Fedora Core and installed in /usr/local (which, on the test system, was a separate partition shared across all distributions). That copy of WINE ran fine with the 64-bit versions of Fedora, Gentoo, and SuSE 9.0, although libXv.so.1.0 had to be copied from the Fedora directory tree to run WINE under SuSE. Mandrake’s 64-bit distribution was tested with an IA-32 WINE binary from the WINE web site with good results, although the binary that shipped with Mandrake crashed when launched. SuSE 9.1′s WINE binary ran fine.
* OPENOFFICE.ORG. All of the 64-bit distributions tested include 32-bit builds of OpenOffice.org. All ran well.
* WORDPERFECT 8. This old program ran fine on all platforms, although old libc5 compatibility libraries had to be installed to make the software run. In the case of Gentoo, you can copy the libc5 ld-linux.so.1 library file to /lib.
* OPERA. For RPM-based distributions, you can install from binary RPMs. Under Gentoo, install from the binary tarball, but be prepared to hack the install script to convince Opera that it’s running on a vanilla IA-32 system.
* CIVILIZATION: CALL TO POWER. This game ran fine on all of the test distributions, except for sound, which was stuttery and awful (probably due to a driver problem).
* FLASH. Macromedia’s Flash is a necessary tool for accessing some web pages. Unfortunately, it’s a commercial product, and is not yet available in AMD64 form. Because Flash is called as a library from a web browser, AMD64-native browsers can’t call Flash. You can configure it to work from a 32-bit browser, though. (In fact, Fedora installs Mozilla as a 32-bit application, perhaps for this reason.) Another option is to try Swfdec (http://swfdec.sourceforge.net), but it’s still a very new project and doesn’t work on many pages.
The Future Is Always Changing
Presently, AMD64 computing is moving out of the bleeding-edge to the leading-edge. The better AMD64 distributions are stable and complete enough that they can be used for many, mainstream computing tasks, particularly if you don’t mind supplementing your software mix with some 32-bit legacy applications. The hardware and software are both new enough that you should exercise some extra caution in picking your system, your Linux distribution, and the individual applications you run.
Future developments are likely to cement AMD64′s place in the computing landscape. With both AMD and Intel pushing the platform, and with the 4 GB memory barrier fast approaching, a shift to AMD64 seems nearly inevitable. The fact that Microsoft is preparing AMD64 releases of Windows XP and Windows 2003 will promote the adoption of the platform as well.
Of course, crystal-ball gazers have been wrong before. The shape of the future can be difficult to discern, even when it’s nearly upon us.
Still, if you want to investigate 64-bit computing in Linux, the AMD64 platform deserves consideration. With distributions already useable and increasing in quality, and with the AMD64′s unique ability to run IA-32 programs well, an investment in AMD64 hardware seems like a safe bet.
Roderick W. Smith is the author or co-author of eleven books, including
Linux Power Tools and The
Definitive Guide to Samba 3. Rod is also Linux Magazine’s “Guru Guidance” columnist. He can be reached at email@example.com.
Linux Magazine /
July 2004 / FEATURES
Linux and the AMD64