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
athlon64; the k8 type is for optimizing 32-bit
code on 64-bit hardware. Also, I didn't install dri because
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 ehurst@ofb.biz.
Join the Conversation
Re: Desktop FreeBSD: 64-bit Future
Suggesting that a 64bit OS can make your soundcard produce better sound? You sir, are an idiot.
Re: Desktop FreeBSD: 64-bit Future
I think this is a good informative article.
You Jan, are are an obnoxious idiot yourself.
Re: Desktop FreeBSD: 64-bit Future
This article contains glaring technical errors. The author obviously has overrated himself.
Re: Desktop FreeBSD: 64-bit Future
I love FreeBSD and I have 4 machines configured with -CURRENT or -STABLE but I’m with Jan on that one…
Re: Desktop FreeBSD: 64-bit Future
Funny, my old/homebuilt 1.2 AMD Athlon (Thunderbird) just died, and yesterday I was looking on Dell’s website; I found the E521 - an AMD64 3200+ / 512Megs DDR2 SDRAM at 533MHz / 80Gig SATA / DVD-ROM drive - for 319$ (just remove the flat panel from the options). What the hell is that? I am going to run Ubuntu AMD64 on it, but now I think I’ll dual boot FreeBSD 6.1 alongside, as I think these boxes are way underrated, what with ever annoying Intel commercial telling everyone that they need a Dual-Core 2 to ‘do more’! Like they need that kind of horse power to check email and view news online…
My home server is FreeBSD 6.0 (no gui) and I couldn’t be happier with it. Ubuntu is my desk, but with a new box and plenty of HD space, I will try out F*BSD64 too. Thanks for the timely write up!
P
Re: Desktop FreeBSD: 64-bit Future
Couldn’t find 32-bit hardware? Where were you, Oklahoma City, North Korea?
Try calling Dell, HP, Compaq, etc. Or, here’s a nickel, go to pricewatch.com and find more 32-bit hardware than you can shake a non-32-bit-working sound card at.
Re: Desktop FreeBSD: 64-bit Future
There is nothing beta about FreeBSD’s amd64 support; amd64 is a tier 1 platform, along with i386, sparc64 and pc98.
Beyond that, I have to agree with Jan here, although I wouldn’t phrase it so strongly; the author seems to have only a superficial understanding of computer technology.
Ed, 64 bits are not automatically better than 32. 64-bit software is up to twice as large and uses up to twice as much memory as the equivalent 32-bit software, and will therefore generally run slower on the same hardware unless it is designed to take advantage of the increased address space. Office software will not benefit much; software that manipulates large amounts of data (image manipulation, CAD/CAM, RDBMS) will. Finally, a 64-bit CPU will usually have more cache and more memory bandwidth than a comparable 32-bit CPU, so it will run memory-intensive software (both 32-bit or 64-bit) faster.
Re: Desktop FreeBSD: 64-bit Future
DES, 64-bit software is NOT twice as large. Why? Because the only the pointers are twice as large — 8 bytes up from 4. But a four byte int is still four bytes, an 8 byte unsigned long is still 8 bytes, and the string “Hello World” does not magically inflate from 12 bytes to 24. I have two packages of rhythmbox right here. The i386 version is 3.6 Megs (compressed), while the AMD64 version is a whopping 3.7. This is typical, and by no means an exception.
General rule of thumb: 64-bits is not just two times 32-bit.
Re: Desktop FreeBSD: 64-bit Future
Adam, that depends on your architecture. On a RISC platform, 64-bit software is twice as large as 32-bit software, because all instructions are exactly 64 bits long. On a CISC platform, some instructions will be longer and some will not; that is why I wrote “up to twice as large” (reading skills aren’t what they used to be, eh?)
Memory usage, however, will grow quite a bit, because most applications store data in fairly small structures with plenty of pointers. Stack usage will also increase significantly.
Umm yes a sound card and driver can work better
… what is so hard to understand? Performance of a sound card can be effected by the driver. It’s very possible that 64bit driver/kernel might produce better sound than the same card running on a 32bit system.
Re: Desktop FreeBSD: 64-bit Future
Anyone is welcome to write their own article for submission, and refute anything or everything I’ve written above. You’d be surprised how easy it is to get accepted. Thin-skinned I am not. Meanwhile, I would suggest people who actually read what I wrote may not draw quite the same conclusions as some of you folks. Many of you react to things I didn’t say.
Re: Desktop FreeBSD: 64-bit Future
Adam- good call, except ‘int’ is the register size the OS supports; on a 32-bit OS it will be 4B, on a 64-bit OS it will be 8B. This would cause a size increase in built-in ‘int’ or pointer constants/initializers, which is still menial, however.
Re: Desktop FreeBSD: 64-bit Future
Adam, and others,
maybe 10 times more if you loaded with 64 x window compare to win32 or apple 8205 chips …. yeah ?
free lane agent, 10/23/06 passing through
Re: Desktop FreeBSD: 64-bit Future
Unfortunatly some essential (to me) packages do not work with freebsd/amd64, like vmware3 (I need to run some windows applications). Other things I like to have is opera, flash7, win32-codecs for mplayer and xine. Is openoffice already working on freebsd/amd64? I also found out linux/i386 emulation on freebsd6.0/amd64 is less stable than on freebsd/i386 (don’t know if it has improved on 6.1), running the linux version of openoffice 2 caused a system crash.
Does amd64, compared to i386, really gain much performance? You already wrote, probably not, except for certain math stuff and compiling. It would be interresting to see some real benchmark results between a CPUTYPE=k8 32bit environment and amd64 64bit environment on the same hardware. It is also not clear how much extra memory (and less important diskspace) 64bit software uses compared to 32bit equivalents. It is uses (much) more it could be a disadvantage.
Unfortunatly the FreeBSD/amd64 kernel is not fully supporting a 32bit userland, like linux and solaris does. In my opinion it would be more desirable if only the parts of the operating system that could gain profit of 64bit computing become 64bit and leave the other stuff 32bit. I think a 64bit kernel for > 4GB memory address space and some 64bit libaries for some userland software that really gain performance in 64bit mode is sufficient, and leave the other stuff 32bit. This is AFAIK also the way Solaris is distributed (correct me if I’m wrong).
Re: Desktop FreeBSD: 64-bit Future
I’ve written above. You’d be surprised how easy it is to get accepted. Thin-skinned I am not. Meanwhile, I would suggest people who actually read what I wrote may not draw quite the same conclusions as some of you folks. Many of you react to things I didn’t say.
Re: Desktop FreeBSD: 64-bit Future
But a four byte int is still four bytes, an 8 byte unsigned long is still 8 bytes, and the string “Hello World” does not magically inflate from 12 bytes to 24. I have two packages of rhythmbox right here. The i386 version is 3.6 Megs, while the AMD64 version is a whopping
Re: Desktop FreeBSD: 64-bit Future
I’m more interested is taking 64bit versions of PostgreSQL 8.3, MySQL 5.x and FireBirdSQL for a spin to see how they fare against their 32bit cousins. Database apps are a great spot for performance improvements.