I understand that the Core 2 Duo is a 64-bit processor, while Core Duo is a 32-bit processor. Let me know if my understanding is wrong. My Linux server, with the Core 2 Duo E8400, is currently running Fedora 9 x32. This machine has 4 Gig of RAM and I don't foresee the need to add any more memory any time soon.

Is there any real advantage to changing from x32 to x64? If so, should I upgrade from Fedora 9 x32 to Fedora 11 x64 (if this form of upgrade is even supported) or should I reinstall? Do I lose anything of value by sticking to x32? From what I have read, it sounds like I don't lose much of anything by sticking with x32, and that performance increases when going from x32 to x64 only for certain special workloads.

This question is similar to but more specific than "Which linux version to install: i386 or x64?," which in fact reminded me that I wanted to ask this question. That question is general, this question is specific to Core 2 Duo since I already have the hardware.

The workload for this server is: light web and EMail server, full NAT for home network, plus light usage NFS/SMB for the home network for music, family photos, and so on.

I think the answer I get will be close to: "Since you've already installed x32 and an in-place upgrade to x64 will be difficult ... and because the gains for x64 are so small for general purpose computing ... wait until your next full install and at that time certainly change to x64." However, this is an area where my knowledge is very incomplete. I won't be surprised if the answer is, "Don't bother," and I won't be surprised if the answer is, "Hey, you should do this at your earliest chance."

  • I think you answered your own question :) – Gareth May 5 '09 at 6:41
  • aaah. please stop calling 32-bit as "x32" , and "x64" is just microsoft marketspeak. – hayalci Jun 7 '09 at 23:32
  • 2
    Not really... according to Wikipedia (en.wikipedia.org/wiki/X64) "The terms x86-64 and x64 are often used as vendor-neutral terms to collectively refer to x86-64 processors from any company." – Sean Earp Jun 8 '09 at 3:02
  • Well, while x64 feels like a valid term, shorthand for x86_64 the x32 should probably just be called x86 to avoid confusion with airplanes and thinkpads :) – Roy Dec 7 '09 at 17:58

In my experience using a 32 and 64 bit variants of FreeBSD on the same hardware, I have seen a measurable (but not huge) benefit to running 64 bit. 64 bit has been around long enough that active projects don't have issues. The one area this is not necessarily true is for compiled commercial apps (doesn't sound like an issue for your workload).

If you were installing from scratch, I'd recommend 64 bit for your workload, but if you've got a working solution in place, I don't think it's worth changing it.


The x86_64 architecture has a few other advantages than just the memory space. The most imporant one is the increased number of registers, which allows the compiler to generate more efficient code.

It's unlikely to make a big difference in the performance of your system though.


Unless you are in need of the full 4gig memory, you probably don't need to go through the pain of performing a full reinstall of your OS. Everything would need to be recompiled to receive the benefit.


The only advantage to moving to 64bit is the ability to address greater than 4GB memory. AFAIK, there aren't any performance benefits to moving to 64bit when working with 4GB or less.

In addition to this, 64bit is still relatively new in the sense that it has not achieved mainstream adoption. (relative compared to the long history of 32bit systems) You could/can run into compatibility issues running 64bit.


Keep in mind there are a few closed-source plugins that don't play very nice with 64-bit. The 64-bit flash plugin beta has been unstable in my experience, and nspluginwrapper with the 32-bit plugin has some interesting quirks (but is livable). I've never managed to get Java applets working with a 64-bit browser...


Performance increase is of 1-3% on calculation intensive applications. The real advantage of 64-bit system is possibility to address more then 4GB of RAM.

On the other hand, the problem is, that there are many closed-source packages available for Linux only in 32-bit packages with 32-bit dependencies. Sometimes can be real pain in the backside.


It depends.

As mentioned by others, some applications work better on 32bit OS vs. 64bit OS. The reverse is also true

As mentioned by others, 64bit OS allows for more RAM access than even 32bit with PAE enabled, although PAE enabled OS can general access a lot of RAM.

What I have found, much to my dismay, is that the chipset/BIOS puts a limit on the maximum memory I can use. Even with 64bit Ubuntu, my system still can only access 3.2GB of RAM.


If you want your OS to be able to use more than 3.5Gb of that ram (possibly a bit less depending on what PCI hardware you have), then yes. Because of the memory layout of 32bit systems some of that physical ram will shadowed by PCI devices and bios memory areas.

  • I thought that the shadowing was only a problem in a virtual address space, meaning no one process could use all 4 GiB. However, since the physical memory is mapped to wherever it needs to go, I thought that all 4 GiB could be used. – Eddie Jun 7 '09 at 20:36
  • On some os's you can use almost all of the 2^32 address space (OS X Leopard comes to mind), however linux always maps some of the virtual address space to the kernel. That is, the kernel takes up some memory in the processes address range. This speeds up context switches, but reduces the amount of memory available to the process – Dave Cheney Jun 8 '09 at 9:25


This could be done, provided you've taken the time to separate your data out from the rest of the system.

Do a fresh 64-bit install on a separate hard drive. Then boot the 64-bit install with your old hard drive attached. Mount the old drive somewhere in /mnt, then glom your data into the new install. Be sure to pick up settings for various services along the way, as well as little bits and pieces in /var/spool/mail, /root, /home, etc. Reboot when finished. If it doesn't work as expected, you lose nothing, your old install is still there.

2009-12-07 Update:

Look at ways you can use background jobs, cron/at scheduling, etc. to help with the transition. Moving bulk data should be something that occurs in a batch job while you get a good night's sleep; and if that isn't a viable option, then you might have to re-think this, or forgo it altogether. Remember, you want the system to work for you - not the other way around.

  • "you lose nothing" - except 6 hours of your time, which in business speak is a lot of time for no gain ;) – Mark Henderson Dec 7 '09 at 7:39
  • If you are expecting to take 6 hours of "on the clock" time to do this, then there is something terribly wrong with how you are managing the transition; that, or you shouldn't bother with it at all. I've migrated live mail systems with less time spent, and that was a paltry 2.5 million messages. Real time taken: 48 hours. My work time taken: about 45 minutes. Plan on backgrounding a job or two, and using the cron/at facilities to help manage this. – Avery Payne Dec 7 '09 at 17:49

Not the answer you're looking for? Browse other questions tagged or ask your own question.