Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm about to make a new Linux install, which will be primarily used for programming. I've seen benchmarks showing speed improvement of 64-bit version, however, I have hard time of telling how much these benchmarks translate to improvement in every day usage. And of course there are other aspects to consider.

Usage I have in mind:

What are pros and cons of choosing either i386 or x86_64 distro?

share|improve this question
MySQL not running out of address space was a good enough reason for me to go for a x86_64 distro, but on 4GB RAM that's probably irrelevant. –  Yannis Rizos Jun 1 '12 at 10:49
The cons of using 64bits platform is that every program consumes more memory. However, when hitting the 4G barrier, 64bits is recommended. –  arnaud Jun 1 '12 at 11:16
@arnaud - Your statement of an application taking "more" memory on a x64 platform is 100% incorrect. 1,024 bytes is 1,024 bytes doesn't matter if its broken into 32 or 64 pieces. –  Ramhound Jun 1 '12 at 13:12
@Ramhound: pointers are 8 bytes on 64-bit, 4 bytes on 32-bit. –  vartec Jun 1 '12 at 13:25
add comment

3 Answers

up vote 8 down vote accepted

In the mainstream Linux-based distro's, the amd64 version is completely on par with the x86 one, so as far as software availability goes, you have nothing to fear either way (a few obscure platform-specific hacks aside). Also, it is possible, albeit with some severe hacking, to run 32-bit code on a 64-bit kernel, so if you absolutely have to, there are probably ways to make that happen. And if all else fails, you can always install a 32-bit virtual machine to compile for that particular architecture.

CPU-performance-wise, there isn't much difference either way: some applications benefit from 64-bit operations (typically, these are applications that have to deal with large integers and such); others don't get any benefit and might even run a tiny bit faster on a 32-bit kernel, especially if they need to handle a lot of natively-sized integers or pointer (which take up twice as much space on a 64-bit platform).

However, if you want to use more than 4 GB of RAM, 32-bit kernels do carry a real performance penalty, because you have to use PAE to make it happen.

As a general rule of thumb, these days I'd say go with 64-bits, unless you have strong reasons not to, most notably:

  • you are using 32-bit libraries that you cannot recompile to a 64-bit platform (e.g. because you don't have the sources)
  • you need to use a package from your distro that isn't included in the 64-bit distribution and cannot be installed from other trusted sources
  • you are short on physical RAM (many programs use significantly less RAM on 32-bit systems, and 'short on RAM' invariably means 'less than 4 GB')
  • you are coding for 32-bit production systems (you want to eliminate as many differences as possible; for example, PHP's ip2long function has a nasty gotcha that only shows on 32-bit systems)
share|improve this answer
add comment

I can only think of two reasons against a 64 bit system:

  1. You have legacy code or a third-party library that doesn't compile on a 64-bit platform.

  2. Your target platform(s) consists mainly of 32-bit systems and you want to make sure your application runs smoothly there without exceeding the 4GB memory limit or compilation problems.

On the other hand, I can't think of many reasons for 64-bit, other than the usually touted "faster & more memory" that (in most cases) isn't all that relevant to everyday development work. This, however, may change over the years (and may already have and I just didn't notice it) once 32-bit platforms are dying out and developers of third-party libraries and other applications are phasing out 32-bit support.

In the end, I don't think there's any harm in using a 64- over a 32-bit OS.

share|improve this answer
You don't think the fact that major software vendors already are saying the next versio of their software will only support x64 is not enough reason at least start to support x64 if you already do not? I forgot which ( video game ) company said their next major ip release will only support x64 systems. –  Ramhound Jun 1 '12 at 13:15
@Ramhound: Even without those unnamed major software vendors of yours, switching over to 64-bit development is a good idea. For some people however, the reality is that the customers still have 32-bit systems and have no intention to invest in an upgrade, either due to financial or logistical reasons. –  Benjamin Kloster Jun 1 '12 at 13:52
add comment

32bits limits you to 4gb, 64bits doesn't. Other than that, it shouldn't bother you much which one you use.

64bits also typically has more memory overhead since memory pointers use 64 bits there instead of 32 bits, so 64 bit programs tend to use up more memory.

Software wise, you typically get everything you need on both. Only for old, unsupported hardware specific legacy stuff, you might run into surprises.

share|improve this answer
32-bits limits me to 64GB, and I've clearly mentioned that I'm not getting more than 64GB. –  vartec Jun 1 '12 at 9:33
@vartec: 32-bits limits you to 4G!!! Why the heck do you think it would be 64G? It's 4G because a pointer in 32 bits can define 2^32 = 4G possible addresses. –  arnaud Jun 1 '12 at 9:33
@arnaud: no they don't. Most Linux distributions automatically install PAE enabled kernels, which limits you to 64GB (and 4GB per process). –  vartec Jun 1 '12 at 9:40
I thought that was mostly specific configurations for servers and data centers. I didn't encountered in on personal computers yet. In both cases, even if "in total", you can have more than 4GB, a single process/program cannot, which is usually what we care about when developing something memory intensive. –  arnaud Jun 1 '12 at 9:43
show 6 more comments

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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