Fedora Core 3 on AMD64 [LWN.net]

December 8, 2004

This article was contributed by Ladislav Bodnar

We continue our series of articles on AMD64 ports of various distributions with a brief look at Fedora Core 3. Based on product reviews and user experiences as expressed on various mailing lists and forums, version 3 is probably the best Fedora release to date. The distribution comes with the very latest kernel, X.Org, GNOME and KDE, the developers seem to have resolved most of the reported issues with SELinux, and the distribution feels polished and generally well-designed. Although not without its flaws, of course, but still a solid and innovative product worthy of an install, even if you prefer another distribution.

After downloading the 2.5 GB x86_64 ISO image, we burned it onto a DVD, and proceeded with installation. For the record, here are the system specifications: AMD64 3500+ processor (2.2GHz), K8N Neo2 (Socket939) mainboard from Micro-Star International, 1 GB of DDR SDRAM, 2 x 120 GB Maxtor hard disks, Plextor PX-712A DVD/CD Rewritable Drive, and NVIDIA GeForce4 Ti 4600 graphics card. Although we chose to install a complete workstation with both GNOME and KDE, as well as all server applications, the installation completed in under 15 minutes. There are no obvious differences between installing Fedora's x86_64 port and its i386 counterpart and once you reboot into your new system, you might be wondering whether this operating system has really been optimized for your 64-bit processor.

We were wondering too, so we decided to take a look at how many of the available Fedora RPMs were compiled for x86_64 systems. Looking through the RPM directories, we found that the x86_64 branch contains a total of 1,619 "x86_64" and "noarch" RPM packages, while the i386 branch lists a total of 1,652 RPM packages. This means that over 98% of Fedora packages have been ported to the AMD64 architecture. By comparison, the Debian unstable branch for AMD64 currently holds 14,911 DEB packages, which represent nearly 96% of all DEB packages found in the i386 architecture.

The remaining packages in Fedora Core were compiled for i386 and are available for installation alongside the x86_64 packages - the most noteworthy among them are Helix Player and OpenOffice.org. Because of this likely mix of 64-bit 32-bit applications on most users' systems, many libraries come in two variants. In fact, looking through the install log, we found no fewer than 52 packages, of which both i386 and x86_64 flavors were installed; this included libgcc, glibc, perl, xorg-x11-libs, gtk2 and many others. On a Fedora system, these two sets of libraries are placed into two separate directories - /lib and /lib64. This is somewhat different from the Debian approach where /lib is just a symbolic link to /lib64, while the ia32 libraries are stored in the /emul/ia32-linux directory. Unlike Debian, Fedora doesn't offer a possibility to install the 32-bit part of the system into a separate, "chroot-ed" environment and the 32-bit and 64-bit libraries and applications coexist on the same system, only separated by the layout of system directories.

The 64-bit Fedora Core 3 has been running rather smoothly on this system. We were impressed by the hardware auto-detection and setup, as well as the overall look and feel of the GNOME 2.8 desktop. But as Fedora Core 3 is really just a base for the upcoming Red Hat Enterprise Linux 4 and therefore lacks many popular desktop applications, we were curious about the availability of third-party RPMs to enhance the multimedia capabilities of the distribution. These are generally made for i386, but what about x86_64? We headed over to freshrpms.net to find out. This turned out to be a mixed-bag experience - there is plenty of good software compiled for i386, but not that much for x86_64. As an example, we tried to install the xmms-mp3 package, but since it was only available for i386, it wouldn't install until we "downgraded" our 64-bit xmms to 32-bit xmms. Other applications fared better and we located pre-compiled 64-bit RPMs of MPlayer, xine, Audacity, Ogle, libdvdcss and other software. Disappointingly, using "apt" to install them proved impossible as each 'apt-get install' command was immediately followed by an enormous list of unmet dependencies. We had better luck with "yum", which worked like magic, even correctly detecting the architecture and automatically downloading and installing 64-bit packages, whenever available.

Given the extra overhead in terms of disk space and memory usage while running two "editions" of the same libraries, as well as the limited number of third-party RPMs, is there a case for running a 64-bit Fedora Core? In other words, are there any advantages of running a 64-bit system on a 64-bit processor, as opposed to running a 32-bit system on a 64-bit processor? As always, it depends. Unfortunately, it seems that right now, and for the majority of users, the disadvantages outweigh the benefits. While we haven't done any speed benchmarks, from what we know about the 64-bit CPUs, most users are unlikely to notice much difference. There might be cases where the 64-bit processors clearly outperform the 32-bit ones, especially in tasks which involve encoding large media files, heavy web serving with scripts and output compression, or running massive databases that require substantial amounts of memory. But users performing everyday office tasks will benefit little from the 64-bit technology.

So why run it at all? Maybe just for that feeling of satisfaction of riding on the cutting edge of consumer technology, not too dissimilar from the feeling of a mountain climber who just conquered Mt. Everest, although he could have chosen to climb a smaller mountain. But there is a second, much more legitimate reason - to avoid the upcoming Year 2038 Bug. That's because on January 19, 2038, at 03:14:07 GMT, exactly 2³¹ seconds will have passed since the beginning of the UNIX epoch on January 1st, 1970. One second later, all 32-bit UNIX systems will revert back to the year 1970. We'll leave it to your imagination as to what will happen unless you migrate your data and applications to a 64-bit system before then.

(Log in to post comments)

Fedora Core 3 on AMD64

Posted Dec 9, 2004 6:13 UTC (Thu) by bos (guest, #6154) [Link]

Certainly, a typical desktop machine isn't going to see much advantage from running a 64-bit distro (whether it's Fedora or anything else), simply because most people don't need the extra address space, and wouldn't notice a few percent of performance difference one way or the other on most typical apps.

Indeed, since some popular apps (e.g. notlame) contain hand-coded 32-bit inner loops, the x86_64 versions can be relatively slow, because they currently fall back to generic C code.

That said, specialist users have needed 64-bit systems for years - ever wondered why Sun dominates the EDA market? - and now they have the opportunity to switch to Linux. Or at least they will once the ISVs pull their thumbs out, which should happen over the next few years.

On a final note, Ladislav says "Unlike Debian, Fedora doesn't offer a possibility to install the 32-bit part of the system into a separate, "chroot-ed" environment" as if this were somehow a good thing. The Debian approach to 64-bit support is suboptimal, since (a) it's incompatible with the x86_64 ABI and (b) it forces you to jump through hoops to run 32-bit apps.

Fedora Core 3 on AMD64

Posted Dec 9, 2004 10:31 UTC (Thu) by ballombe (subscriber, #9523) [Link]

"(a) it's incompatible with the x86_64 ABI"

That's not true, no. Debian x86_64 variant pure64 is fully compatible with the x86_64 ABI published by the LSB, both way.

"(b) it forces you to jump through hoops to run 32-bit apps."
That might look like hoops, but it is much more cleaner and powerful since it let you install any packages (not just libraries) in the variant (32,64 or both) of your choice.

Beside, chroot is a wonderful technology with Debian and it deserves to be more widely used.

Fedora Core 3 on AMD64

Posted Dec 9, 2004 12:00 UTC (Thu) by nix (subscriber, #2304) [Link]

That said, specialist users have needed 64-bit systems for years - ever wondered why Sun dominates the EDA market? - and now they have the opportunity to switch to Linux.

Because, of course, Linux has never worked on UltraSPARC or anything, and certainly has never been able to run 64-bit userspace apps there.

Fedora Core 3 on AMD64

Posted Dec 9, 2004 17:25 UTC (Thu) by bos (guest, #6154) [Link]

Linux has worked on UltraSPARC for years, fully 64-bit.

Fedora Core 3 on AMD64

Posted Dec 9, 2004 23:01 UTC (Thu) by xorbe (subscriber, #3165) [Link]

I think nix was making a joke.

Fedora Core 3 on AMD64

Posted Dec 10, 2004 7:36 UTC (Fri) by nix (subscriber, #2304) [Link]

The phraseology made the mild sarcasm fairly clear (or at least I hoped it did; obviously not clear enough).

Fedora Core 3 on AMD64

Posted Dec 13, 2004 20:36 UTC (Mon) by knut (guest, #4309) [Link]

Well, every joke/sarcasm contains a grain of truth :-)

Have a look at the Linux Ultra FAQ, question 1.5:
(http://www.ultralinux.org/faq.html#q_1_5)

5. Is everything 64-bit on sparc64, and can I compile 64-bit applications ?

The kernel and kernel modules are 64-bit on sparc64, userland is still 32-bit, and in fact the same as on sparc32. The conversion between native 32- and 64-bit function calls is being done via the kernel. Allthough you can compile a kernel with egcs64, you can't really use this compiler for building 64-bit userland binaries. See also "Why can't I compile certain software on my sparc64 ?" in Section 9.

Best regards,

Knut

Fedora Core 3 on AMD64

Posted Dec 14, 2004 23:38 UTC (Tue) by nix (subscriber, #2304) [Link]

That FAQ entry is grossly outdated. GCC-3.2+ is able to compile 64-bit apps perfectly well on sparc64 (my kernel is compiled with 3.4.3 as are most of the 64-bit apps I use, and none show any ill effects).

I deleted the ancient egcs-19980921.1 compiler nearly a year ago, and haven't missed it once.

I have a number of 64-bit apps and libs here (XEmacs and dependencies, Octave, the backup program dar(1) which eats address space for breakfast), although the majority are still 32-bit (and will stay that way, because 32-bit stuff is generally faster than 64-bit stuff on UltraSPARC because all the instructions and pointers are smaller so it keeps memory fetches down).

Fedora Core 3 on AMD64

Posted Dec 10, 2004 21:01 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link]

(sarcasm noted)

Just because there's Linux on UltraSPARC doesn't mean people flock to it in droves. I'd imagine many places with a large deployment of SPARCs also have Sun service contracts, and so run Solaris.

EDA software on x86/x86_64 is what'll bring Linux to these people.

Desktops usually no; Servers yes.

Posted Dec 9, 2004 16:43 UTC (Thu) by dwheeler (guest, #1216) [Link]

The main advantage of 64bit systems is that more than 4G of memory is directly addressible. Whether or not that's a useful advantage depends on what you do with your system.

Currently, most desktop users will be quite happy with 32bits. One exception is some high-end CAD systems, where you want in-memory simulations that take more than 3Gig of memory.

But some large servers, especially large database servers, can really use this. Database systems work better if there's lots of memory, for example, and it's easier to address lots of memory given a 64-bit address space.

The Wikipedia database currently runs on 32bits; they've considered switching to 64bits, but at the time the costs and leading-edge-ness convinced them to stay with 32bit systems. As these get addressed, they'll probably move to a 64-bit system for their main database.

Many large commercial outfits run databases on 64bit systems, for this reason.

Desktops usually no; Servers yes.

Posted Dec 9, 2004 19:02 UTC (Thu) by knobunc (subscriber, #4678) [Link]

What about the extra registers available in 64-bit mode? That alone is enough to speed up some tasks regardless of memory needed.

More registers = less register spilling. Means less stack access when calling subroutines. Compilation is a good example of when this is useful.

-ben

Desktops usually no; Servers yes.

Posted Dec 9, 2004 20:41 UTC (Thu) by evgeny (guest, #774) [Link]

> The main advantage of 64bit systems is that more than 4G of memory is directly addressible.

Well, to me (and many others), it's also working at native CPU speeds with 64bit data types (doubles and long longs).

Desktops usually no; Servers yes.

Posted Dec 10, 2004 0:27 UTC (Fri) by sbergman27 (subscriber, #10767) [Link]

Does 64bit really help for doubles? I thought that FPU's on current 32bit processors handled 80 bits or so.

Desktops usually no; Servers yes.

Posted Dec 10, 2004 12:17 UTC (Fri) by evgeny (guest, #774) [Link]

> Does 64bit really help for doubles?

Well, at least for my codes it does. YMMV ;-)

> I thought that FPU's on current 32bit processors handled 80 bits or so.

P3 is not bad, and Centrino is even better (per GHz). But you can't get SMP boxes with Centrino, and CPU speed is not high. P4/Xeon4, on the other hand, is a complete disaster as far as doubles and longlongs are concerned - again, this is my experience. Try running md5sum on a large file (e.g. an iso image) on a P3, P4, and Opteron boxes (of course, with 64bit kernel and md5sum binary in the last case) - and compare the (user) times. I even tried the Intel's ICC compiler - all the same. Switching from x86 to amd64 got me a factor of ~2 (per GHz) comparing to P3 and ~4 (!) comparing to P4.

Desktops usually no; Servers yes.

Posted Dec 10, 2004 21:08 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link]

What does md5sum have to do with floating point?

The speedup on md5sum probably comes from doubling the number of integer registers, and thereby reducing register spills to the stack.

At any rate, doubling the integer register file should have a minimal impact on floating point codes, since all floating point computation occurs in the floating point register file. One area floating point code will see speedups is in block copies. Non-computational manipulation of floating point data in the integer register file (stuff like memcpy(), structure assignment, array initialization) will speed up.

Desktops usually no; Servers yes.

Posted Dec 10, 2004 22:31 UTC (Fri) by evgeny (guest, #774) [Link]

> What does md5sum have to do with floating point?

Not with FP; with (64bit) long longs. Hmm, or, at least, that was my impression. I did some benchmarks a year ago and noticed that a couple of utilites worked much better on amd64 than on x86; and it seemed it was related to the use of 64bit variables/structs..

> The speedup on md5sum probably comes from doubling the number of integer registers, and thereby reducing register spills to the stack.

Probably you're right.

> One area floating point code will see speedups is in block copies.

That's definitely not the case with my numbercrunching codes. Furthermore, running 32bit exec under 64bit kernel takes exactly twice more CPU time than the 64bit executable.

Desktops usually no; Servers yes.

Posted Dec 10, 2004 3:28 UTC (Fri) by mbp (guest, #2737) [Link]

I find it very strange that most(?) AMD64 desktops currently available can accomodate less than 4G of RAM. Even if >4G is slightly expensive now, you'd think people switching would want at least the possibility of upgrading to say 8G in a year or so.

I don't really know what I'd do with 8G on a desktop though.

Desktops usually no; Servers yes.

Posted Dec 10, 2004 5:42 UTC (Fri) by proski (subscriber, #104) [Link]

Nothing strange. 4 Gb of memory is still too expensive for a desktop. Ability to address more memory is only one advantage of 64-bit architectures. There are other advantages, such as 64-bit arithmetic and (in case of AMD64) new registers.