Why should we build 64 bit targets for C++ application? [closed]

Answer 1

The size of data types does not automatically double with x64, but the size of the processors registers, just as the pointer size does. With 32 bits you are able to address 4294967295 bytes of memory (~ 4 Gb), which is not enought for some applications (like database management systems, ...).

Firefox is only available in 32-bit, because of compatibility issues. You cannot write libraries for x86 (32 bit) architectures and call them from x64 processors, because their pointers are incompatible (as described above). Creating both: x64 and x86 versions increases test-expense. If your application rarely uses more than 3.5 Gb memory, then it doesn't actually profit from x64 architectures.

Also 32 bit programms cannot simply run on x64 architectures. On Windows there is a layer for this, called Windows on Windows (WoW), or WoW64 for x64/x86 interfaces. Through various caching cases it may also be that an x86 application runs actually faster on WoW, than an native x64 application, doing the same.

Answer 2

Aside from the OBVIOUS reasons given above (mainly "using more than 2-3GB of memory"), the reason to compile for 64-bit is that x86-64 has 16 registers, where x86-32 has 8. Since one of those registers is the stackpointer and often rBP is reserved for "framepointer", the actual useful number of registers is 6 and 14 respectively. The additional registers allow, for example, larger number of parameters being passed in registers, and larger number of temporary variables being held in registers within a function. This has a positive effect on the actual execution speed of the code, as every time memory is used instead of a register, AT LEAST it leads to a more complex instruction, and often to an additional instruction having to be used. This in turn makes the code larger when there isn't enough registers.

Generally, 64-bit x86 code runs some 5-15% faster with no modification to the actual algorithms, and typically has . Sometimes algorithms can be changed to gain much more [because for example you can have an array that is indexed by "telephone number", instead of hashing the phone number and then indexing on the hash, or making use of 64-bit integer values instead of 32-bit ones, meaning a speedup of 2x for "half as many operations"].

If it's performance you need from the application, you will have to benchmark (on multiple platforms). There are situations where, for example, larger pointers, mean that cache gets full more quickly and the code ends up running slower because "only half as many linked list entries fit in the cache".

In short: In most cases, 64-bit apps are faster than 32-bit apps doing the same thing.

Answer 3

• Physical memory

A 32-bit system architecture can directly address only a 4-GB address space. A 64-bit system architecture that is running a 64-bit edition of Windows Server can support up to 1,024 GB of both physical and addressable memory.

• Better parallel processing

A server that is using 32-bit architecture is limited (Windows OS) to 32 CPUs. Improvements in parallel processing and bus architectures enable 64-bit environments to support as many as 64 processors and provide almost linear scalability with each additional processor.

• Faster bus architecture

A 64-bit architecture provides more and wider general-purpose registers, which contribute to greater overall application speed. When there are more registers, there is less need to write persistent data to memory and then have to read it back just a few instructions later. Function calls are also faster in a 64-bit environment because as many as four arguments at a time can be passed in registers to a function.

Answer 4

The most important usecase is when you really want to consume more than 2 gigabytes memory for your process.

The next thing is 32-bit support will slowly decline just like you won't see many 16-bit apps now. This is a slow process though. Currently there's one version of Windows Server 2008 that doesn't have 32-bit support by default.

And finally sometimes you just have to be 64-bit - that's when you build an extension of any kind that is loaded into a 64-bit consumer process. Since 64-bit processes can't load 32-bit code you have to supply a 64-bit extension for them or craft an interop solution to have your code in a separate process - the latter is not always possible and is sometimes very inefficient.