Fedora Core 3 on AMD64
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 231
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.
| Index entries for this article | |
|---|---|
| GuestArticles | Bodnar, Ladislav |
Posted Dec 9, 2004 5:48 UTC (Thu)
by pynm0001 (guest, #18379)
[Link] (2 responses)
That's because on January 19, 2038, at 03:14:07 GMT, exactly
231 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. Well to be fair, 32-bit systems could convert
Posted Dec 10, 2004 20:58 UTC (Fri)
by jzbiciak (guest, #5246)
[Link] (1 responses)
Posted Dec 11, 2004 20:15 UTC (Sat)
by Thalience (subscriber, #4217)
[Link]
Posted Dec 9, 2004 6:13 UTC (Thu)
by bos (guest, #6154)
[Link] (8 responses)
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.
Posted Dec 9, 2004 10:31 UTC (Thu)
by ballombe (subscriber, #9523)
[Link]
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."
Beside, chroot is a wonderful technology with Debian and it deserves to be more widely used.
Posted Dec 9, 2004 12:00 UTC (Thu)
by nix (subscriber, #2304)
[Link] (6 responses)
Posted Dec 9, 2004 17:25 UTC (Thu)
by bos (guest, #6154)
[Link] (4 responses)
Posted Dec 9, 2004 23:01 UTC (Thu)
by xorbe (guest, #3165)
[Link] (3 responses)
Posted Dec 10, 2004 7:36 UTC (Fri)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Dec 13, 2004 20:36 UTC (Mon)
by knut (guest, #4309)
[Link] (1 responses)
Have a look at the Linux Ultra FAQ, question 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
Posted Dec 14, 2004 23:38 UTC (Tue)
by nix (subscriber, #2304)
[Link]
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).
Posted Dec 10, 2004 21:01 UTC (Fri)
by jzbiciak (guest, #5246)
[Link]
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.
Posted Dec 9, 2004 12:50 UTC (Thu)
by stevem (subscriber, #1512)
[Link] (1 responses)
Posted Dec 9, 2004 19:06 UTC (Thu)
by spitzak (guest, #4593)
[Link]
0x7fffffff -> Tue Jan 19 03:14:07 AM GMT 2038
Posted Dec 9, 2004 16:43 UTC (Thu)
by dwheeler (guest, #1216)
[Link] (8 responses)
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.
Posted Dec 9, 2004 19:02 UTC (Thu)
by knobunc (guest, #4678)
[Link]
More registers = less register spilling. Means less stack access when calling subroutines. Compilation is a good example of when this is useful.
-ben
Posted Dec 9, 2004 20:41 UTC (Thu)
by evgeny (guest, #774)
[Link] (4 responses)
Well, to me (and many others), it's also working at native CPU speeds with 64bit data types (doubles and long longs).
Posted Dec 10, 2004 0:27 UTC (Fri)
by sbergman27 (guest, #10767)
[Link] (3 responses)
Posted Dec 10, 2004 12:17 UTC (Fri)
by evgeny (guest, #774)
[Link] (2 responses)
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.
Posted Dec 10, 2004 21:08 UTC (Fri)
by jzbiciak (guest, #5246)
[Link] (1 responses)
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.
Posted Dec 10, 2004 22:31 UTC (Fri)
by evgeny (guest, #774)
[Link]
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.
Posted Dec 10, 2004 3:28 UTC (Fri)
by mbp (subscriber, #2737)
[Link] (1 responses)
I don't really know what I'd do with 8G on a desktop though.
Posted Dec 10, 2004 5:42 UTC (Fri)
by proski (subscriber, #104)
[Link]
Posted Dec 10, 2004 18:17 UTC (Fri)
by wsand70 (guest, #4482)
[Link]
Has it been a total waste? I don't think so... I remain optimistic for the near future of pure 64. But hey, it's also nice to fall back on 32 if need be. Wouldn't want a total lockout.
Posted Dec 15, 2004 3:23 UTC (Wed)
by csamuel (✭ supporter ✭, #2624)
[Link]
Posted Dec 16, 2004 10:46 UTC (Thu)
by Milan (guest, #26716)
[Link]
Posted Dec 16, 2004 13:16 UTC (Thu)
by scharkalvin (guest, #7372)
[Link]
Year 2038 problem
time_t to a
64-bit type
instead of upgrading the system to a 64-bit processor. You would of
course still need to modify the system libraries and applications
however.
That still won't fix broken binaries that shove time_t into a 32-bit int. Year 2038 problem
True, but broken binaries will still be broken on a 64-bit system. There is no hope for existing 32-bit binaries.Year 2038 problem
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.Fedora Core 3 on AMD64
"(a) it's incompatible with the x86_64 ABI"Fedora Core 3 on AMD64
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.
Fedora Core 3 on AMD64
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.
Linux has worked on UltraSPARC for years, fully 64-bit.Fedora Core 3 on AMD64
I think nix was making a joke.Fedora Core 3 on AMD64
The phraseology made the mild sarcasm fairly clear (or at least I hoped it did; obviously not clear enough).Fedora Core 3 on AMD64
Well, every joke/sarcasm contains a grain of truth :-)Fedora Core 3 on AMD64
(http://www.ultralinux.org/faq.html#q_1_5)
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).Fedora Core 3 on AMD64
(sarcasm noted)Fedora Core 3 on AMD64
When time_t wraps, it'll go negative. Depending on the bugginess of the platform, we may see crashes, 1970 or 1901...Fedora Core 3 on AMD64
Yep it goes negative, on Linux at least (using clock format from tcl, which I think is Fedora Core 3 on AMD64
calling the glibc function):
0x80000000 -> Fri Dec 13 12:45:52 PM PST 1901
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.
Desktops usually no; Servers yes.
What about the extra registers available in 64-bit mode? That alone is enough to speed up some tasks regardless of memory needed.Desktops usually no; Servers yes.
> The main advantage of 64bit systems is that more than 4G of memory is directly addressible.Desktops usually no; Servers yes.
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.
> Does 64bit really help for doubles?Desktops usually no; Servers yes.
What does md5sum have to do with floating point?Desktops usually no; Servers yes.
> What does md5sum have to do with floating point?Desktops usually no; Servers yes.
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.Desktops usually no; Servers yes.
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.
Desktops usually no; Servers yes.
I enjoyed this review. I was hoping the results would be much better than what FC2 is at on my AMD64. It has been an interesting journey to say the least. I have been asked of its benefits often and found it hard to answer. It is tough at time to finagle with both sets of RPM's prior to learning there were both 64 and 32 bit apps running. Never occurred to me it wasn't pure 64. Foolish I know. At any rate I run this as a desktop and the biggest pain so far has been the lack of 64 bit Mozilla plugins namely the flash plugin.Fedora Core 3 on AMD64
Here at VPAC we run a small dual Opteron cluster for HPC work with Fedora Fedora Core 3 on AMD64
Core 2 and the guy looking after it will shortly upgrade it to FC3.
Both work really well and FC3 even comes with a preview of GCC-4 with a
Fortan-95 compiler.. :-)
The next reason for moving to AMD64 (x86_64) is to have NX bit in place. So there is a better chance to defence against a lot of security flaws.NX on AMD64
Actually it seems that even 64 bit systems will have the y2038 bug.Fedora Core 3 on AMD64
With the current gcc sizeof(int) yields 4 NOT 8 on an amd64 system.
Same as on I32. If GCC fixes this the problem will go away.
I bet the kernel just changes time_t to a long int instead.