Consumer grade machines with 64-bit processors have been around for the past three years. At first it meant nothing, since the ones you could buy off the shelf came with 32-bit Windows XP. However, that's still the case, as 64-bit Windows drivers have lagged for most consumer hardware. Not so in the Open Source world, where the greatest source of complaints -- poor or missing drivers for some hardware -- is its greatest strength in the 64-bit arena.
Not relying on the manufacturers, such drivers as exist in Linux and Unix have already been ported, and work equally well with whatever architecture is supported. If your favorite Linux distro runs on your CPU, it's almost guaranteed video cards, audio chips, etc., all work about the same. While FreeBSD for AMD64 is considered still somewhat beta quality, my experiment has so far yielded excellent results.
Why is it taking so long for the industry, commercial and Open Source, to fully embrace 64-bit? It's all over the place in server rooms, but not much on the desktop. So far, the difference in user experience doesn't justify the hassles of migrating. Yet there's no doubt this is the future of computing. It seems to me gaming and virtual reality are the kinds of stuff that will eventually drive 64-bit development popularity. All software is getting fatter and heavier, and will take ever more RAM, That's one of the few currently acknowledged advantages with 64-bit. Even in business applications, with the likes of huge packages such as OpenOffice.org, we have about bumped up against the speed limit of 32-bit hardware. Except for a few gaming and graphics applications, a 2Ghz work station is about the same as a 4Ghz; the difference is hard to notice. Too many other factors can make a big difference. Faster processors and faster bus speeds won't give us a perceptible advantage in using office suites. Yet the OpenOffice devs have only recently produced a 64-bit ready version of their code-base.
With the development of 64-bit CPUs, we get 64-bit highways across the motherboard for everything. We lose the advantage of hand-coded optimization with assembly language, but then we no longer need it. We can continue developing larger and more complex software and do it faster with a development environment coders are likely to find simpler to use. Let's face it: While moving to 64-bit may not solve all the problems, the voice-controlled system with 3D projections predicted in science fiction could never be a reality on 32-bit processors. Such advancement would require developers pass off ever more complexity to the computer just to develop. Today's standard systems won't take us there.
Try to find hardware today for 32-bit. It's getting harder. My computer ministry received a donated machine which had been used as a light server. The case and power supply were fine, as were the RAM stick and video card, but the K7 board and CPU both had failed. In checking with local vendors in Oklahoma City where I live, no one had compatible boards except 64-bit. We managed to obtain a K8 board and CPU bundle on clearance, already obsolete. Someone else offered an extra RAM stick too cheaply to say no. Thus, we ended up with this:
The board, CPU, extra RAM, and harddrive cost us $250. Please note
all of this was the lowest end we could find, and almost everything you
might buy now is better than this. Following the normal procedure for a fully
optimized install of FreeBSD, I built 6.1 for AMD64. The primary
difference is in
/etc/make.conf. The CPU type is
k8 type is for optimizing 32-bit
code on 64-bit hardware. Also, I didn't install
as yet there are no full hardware acceleration drivers for nVidia (nor
ATI) cards on FreeBSD AMD64. If you are using a graphics chipset with
fully open sourced drivers, that's different. Also, Mozilla has been
replaced with Seamonkey.
For now, there's no compelling reason to make that change for most business and home office users. That is, unless you are buying machines now for the future. Early adopters take more risks, but often gain something for mere persistence. You can run 32-bit FreeBSD on a 64-bit machine, and it's likely to be just fine. However, you are increasingly likely to run into small problems here and there, as I did. The onboard sound is provided by the VIA 8237 chipset was fairly low quality under every 32-bit OS we tested (WinXP, CentOS 4, & Kanotix). However, under every 64-bit OS (CentOS, Kanotix, FreeBSD), they worked much better. I note FreeBSD AMD64 gave the best results of all, with smooth full sound regardless of the sound server being used. More and more, I suspect onboard hardware will need 64-bit drivers to take full advantage of its capabilities.
The one place where a dramatic difference came to light was during
the optimized build from source. While this is a low-end machine for
AMD64, it was the fastest build ever for me, including a 32-bit system
with a faster processor. The basic
buildworld was a mere
1.5 hours, and
buildkernel was less than 20 minutes. This,
when 32-compatibility was selected, which added quite a bit to the job.
Further, building KDE in the same order took about half as long as the
previous best of 2 days.
Obviously, because of the 32-bit compatibility, it's possible to build every port that isn't broken. Out of 15,000+ ports, about 500 are strictly for 32-bit. Thus, in most instances, unless you need 3D acceleration for your nVidia or ATI video card, it costs you nothing to switch. As computer technology moves forward, you'll already have the established base and experience working with FreeBSD 64-bit. It's not about higher performance except in compiling software, high-end graphics rendering, and math-intensive work such as compressing files or in complex cryptology applications. It's about future-proofing.
Ed Hurst is Associate Editor of Open for Business. Ed operates a computer ministry in Oklahoma City. He loves computers, runs FreeBSD and GNU/Linux and reads all sorts of things. You can reach Ed at firstname.lastname@example.org.
|Home About Connect: Twitter Facebook RSS|