Transition to 64 bit - Pain or Panacea ?

Once in a while the 64 bit moniker raises its head and promises to administer a much needed testosterone boost to whatever is ailing the computing industry. Most recent example is Apple with its IOS 7 release. Yet the facts are far different detached in most cases with this marketing hype created.

64-bit at a programming level comes with the promise of more registers in the CPU, the ability to process larger data (64 bits at a time) than 32 bit and ofcourse an understated/unspecified improvement in the basic CPU architecture (say removing flaws of the 32 bit architecture). To be frank the first two capabilities effect a certain class of math intensive applications like image processing, signal processing, compression/decompression, security algorithms etc. But not everything under the sun can get significant jumps.

Infact most general purpose applications are not written from scratch for 64 bit (as it should be), but are ported. Those applications are optimized for a 32 bit architecture, and when compiled with minimum changes for 64 bit can work on 64 bit but are not tuned for it. It results in no gains whatsoever in many cases, despite the compiler using some of the extra registers and sometimes come with a performance penalty. Surprise ! Surprise !! Surprise !!! 

The reason are that many routines in C/C++ which are not CPU compute intensive cannot use all the extra registers and benefit somewhat little by the extra registers and ofcourse the understated newer & better CPU architecture. To make matters worse the data which was aligned for 32 bit (and multicore cache lines) is sometimes thrown out of alignment for 64 bit which imposes a performance penalty (memsets, memcopy, etc can become heavier for structures). The net result varies and is anybody's guess but definetely not what the 64 bit technology promised in the marketing materials. And as long & pointers (and sometimes ints in some architectures) data are now 64 bit instead of 32, in general the dynamic footprint also increases and this increase is sometimes upto 30%. And sometimes our programmer who ported has not used all the possible static analyzers correctly, or supressed compiler warnings that resulted in some bad type conversions to linger around that crash sometimes when values greater than a 32 bit integer range could hold but work fine when the values are within the 32 bit range !!! So instead of a higher performance you expected,  you end up getting  a 30% code bloat and maybe a 10% drop in performance and top it a few of random bugs (Heisenbugs) leading to a question mark on stability. I have seen scene this play out many a times. 

And if you are using an IOS 7 on iPad or IPhone 5S, you may have observed that after migrating to IOS 7 the low memory errors, random crashes Safari (with multiple tabs), frequent browser tab refreshes and crashes in other apps have increased with the diagnostic data pointing to low memory (which was otherwise absent in 32-bit IOS 6).

My intention is not to blow a  gun on your face and scare you off 64 bit Computing. 64 bit was meant for applications that need to use more than 2 or 3 GB addressable memory space in one process (IPhone/iPad have 1 GB RAM). Those are anyways not very common in general purpose applications. Maybe for large in-memory databases(caches) or scientific computing applications. And a majority of applications don't need 64 bit. So if you are a developer, look before you leap. And for those who can benefit from 64 bit, my advice would be to:

(1) Compile the code with the highest level of compiler warnings and ensure that the warnings don't point to 64 bit problems

(2) Use static PClint, KlocWorks, Coverity, Viva64 etc (better to include a special 64 bit code checker oif available) to detect 64 bit errors and get rid of them

(3) Wherever you are casting pointers to integers and vice-versa, check it carefully.

(4) Expect Code bloat. If its not acceptable you may have to use compilert size optimization and/or hand-tuning (wondering what apple and IOS app developers are going to do)

(5) Measure performance and tune data structures to play nicely on 64 bit and Multi-core cache lines

(6) Test Comprehensively.

I am not aware of a test method which can ensure that all pointers are greater than 32 bit range even if run on a machine with more than 4G physical RAM. So very strict static analysis and code review is your best bet to remove heisenbugs, even though you may be having a very comprehensive test net.