Long gone are the times when 64 bit memory addressing was the prerogative of Itanium, SPARC, RISC processors, PowerPC, etc. Now almost every desktop PC is built on the x86-64 architecture, let alone servers. x64 has become cheap, opening new horizons for a variety of applications. Surely, those who already run (or are about to run) x64 platforms have long-term thinking: taking the pains to migrate to x64 today will pay off manifold in the long run.

Migrating to x64 becomes an especially sensible issue when it comes to image processing. If you haven’t dealt with anything larger than 5000x5000 pixels, you would not probably be reading this article. Otherwise, you might witness your applications throw ‘out of memory’ errors from time to time – and think about lifting the 2-Gb-per-process curse. Install more memory (if necessary) and switch to x64 platform – it’s often just as simple as that. This was essentially the main idea behind porting here at Aurigma.

However, the (often seemingly) cumbersome and costly nature of migrating to x64 is often the key factor in saying ‘no’ to the natural solution to the problem. So, developers are forced to find roundabouts for ‘out of memory’ troubles. Some of those ‘remedies’ are highly performance taxing and are fraught with development and debugging implications. These often outweigh the possible benefits. Also, the added developmentdebugging cost would often exceed the cost of migration of an entire farm to x64.

On the other hand, more and more applications and services are ported to x64 and some are native x64 – and those are no longer limited to scientific computing and complex mathematical modeling tasks. In fact, x64 for servers has become an industry standard for quite a while. So, if having a legacy 32 bit application prevents you from switching your IIS permanently to 64 bit, I would reply with a marketer-standard call to action: ‘Think big – go x64!’, or even more pesky – ‘Enlarge your address space now!’.

So, what are the costs of saying bye-bye to ‘out of mem’? For , it means replacing a couple of DLLs in the API. If you ask me, I would say it’s certainly at the least. Eventually, it’s up to you to decide whether to ‘stay x86 and reinvent the page file’ or ‘harness the brute raw power of x64’ (I think I’ll can those two for future use).