62

Is there any good reason to supply a 32-bit version along with a 64-bit version of any software targeted at modern desktop machines, running modern 64-bit operating systems on 64-bit hardware?

It seems that 64-bit software would be more efficient, allow for higher memory usage if needed, etc. Apple even uses 64-bit processors for their phones, even though they only have 1-2 GB of RAM, way below the 4 GB limit for 32-bit CPU's.

Peter Mortensen
  • 1,045
Drathier
  • 2,873
  • 3
  • 18
  • 21

4 Answers4

84

Benefits of 32-bit software in 64-bit environments

  • Lower memory footprint, especially in pointer-heavy applications, 64-bit vs 32-bit can easily double the memory requirements.
  • Object files are smaller as well.
  • Compatibility with 32-bit environments.
  • Memory leaks are hard capped to 2 GB, 3 GB, or 4 GB and won't swamp the entire system.

Drawbacks of 32-bit software in 64-bit environments

  • 2 GB, 3 GB, or 4 GB memory limit per process. (Just per process, in sum multiple 32-bit processes may use the full available system memory.)
  • Not using additional registers and instruction set extensions depending on x64. This is highly compiler and CPU specific.
  • May require 32-bit versions of all (most Linux distributions) or uncommon (most Windows versions) libraries and run time environments. If a 32-bit version of a shared library is loaded exclusively for your application, and that counts towards your footprint. No difference at all if you are linking statically.

Other aspects

  • Drivers are usually not an issue. Only user-space libraries should differ between 32-bit and 64-bit, not the API of kernel modules.
  • Beware of different default widths for integer datatypes, additional testing needed.
  • The 64-bit CPU architecture may not even support 32-bit at all.
  • Certain techniques like ASLR and others depending on a much larger address space than physical memory won't work well (or at all) in a 32-bit execution mode.

Unless comparing a very specific CPU architecture, operating system and library infrastructure here, I won't be able to go into more details.

Peter Mortensen
  • 1,045
Ext3h
  • 1,374
8

The difference between 32 bit software and 64 bit software is the size of the pointers, and maybe the size of the integer registers. That's it.

That means all pointers in your program are twice the size. And (at least on an ILP32/LP64 architecture) your longs are twice the size as well. This typically works out to about a 30% increase in object code size. This means that …

  • your object code will take ~30% longer to load from disk into RAM
  • your object code will take up ~30% more space in memory
  • you have effectively lowered your memory bandwidth (for object code) by ~20%
  • you have effectively lowered the size of the instruction cache by ~20%

This has a non-negligible negative effect on performance.

Doing this only makes sense if you can "buy back" those performance costs somehow. Basically, there are two ways to do this: you do a lot of 64 bit integer math, or you need more than 4 GiByte mapped memory. If one or both of those is true, it makes sense to use 64 bit software, otherwise it doesn't.

Note: there are some architectures where there are no corresponding 32 or 64 bit variants. In that case, the question obviously doesn't make sense. The most well-known are IA64, which is only 64 bit and has no 32 bit variant, and x86/AMD64 which are, albeit closely related, different architectures, x86 being 32 bit only, AMD64 being 64 bit only.

Actually, that latter statement is not 100% true anymore. Linux recently added the x32 ABI, which allows you to run AMD64 code with 32 bit pointers, so even though that's not a "proper" CPU architecture, it is a way of using the AMD64 architecture in such a way as if it had a native 32 bit variant. This was done precisely because the performance overhead I mentioned above was causing real measurable, quantifiable problems for real-world users running real-world code in real-world systems.

Jörg W Mittag
  • 104,619
6

If the software needs to interface directly with legacy systems, drivers or libraries, then you may need to supply a 32-bit version, since AFAIK the OS generally (definitely Windows and Linux AFAIK) doesn't allow mixing of 64-bit and 32-bit code within a process.

For example, if your software needs to access specialty hardware, it's not uncommon for customers to operate older models for which only 32-bit drivers are available.

​

Peter Mortensen
  • 1,045
Michael Borgwardt
  • 51,502
4

If your software is a DLL, you MUST provide both 32-bit and 64-bit versions. You have no idea whether the customer will be using 32-bit or 64-bit software to talk to the DLL, and the DLL has to use the same bit-length as the application. This is non-negotiable.

If your software is a standalone executable, it's less clear. If you don't need your software to run on older OSes, you may not need to provide a 32-bit version. Just stick to 64-bit, specify that it requires a 64-bit OS, and job done.

However if you do need your software to run on older OSes then you may actively NOT want to provide a 64-bit version. If you have two versions then you have double the testing, and properly testing software across a range of OS versions and languages is not a quick process. Since 32-bit software runs perfectly happily on a 64-bit platform, it's still fairly common for software to be released only as 32-bit, especially by smaller developers.

Also note that most mobiles are 32-bit. Maybe some high-end ones are 64-bit now, but there's little compelling reason to make that step. So if you're developing cross-platform and might want your code to run on Android as well, staying 32-bit is a safe option.

Graham
  • 2,062