Over at techreview.com, Simson Garfinkel has written a thoughtful article about whether moving from 32 to 64 bit computing makes much sense.

While I agree with most of the detail of his article, I think he has missed a few points, and I don't entirely agree with his conclusions.

I agree that "64 bit math" is a red herring. I'm astonished that so much emphasis is still placed on numerical capabilities in IT systems. When I first learned about computers back in the late 1970s, they were considered fundamentally numerical devices. The example applications everyone trotted out in classes were things like weather prediction and ballistics modelling. The first computer they got at my school was the sole preserve of the maths department. These days it's completely different. Anything numerical that regular folks need is done with specialist hardware. Ask any hardcore gamer if he'd rather have polygon rendering and shading done by the main CPU! Computers in the early 21st century are almost exclusively used for information storage, transfer and reformatting.

When we get to the potential need for 64 bit memory addressing, I begin to have doubts about the conclusions in the above article. Personally, I'm drooling in anticipation of a new wave of systems with massive memory capability (and the lowering of the price of bulk RAM that I hope will accompany it.) Todays low-cost systems with their typical maximum 1-2GB of RAM are a major roadblock to several types of applications. Let's look at a couple of examples:

• Video Editing Desktop video is getting better and better, but it's still not as simple and reliable as vendors would have you believe. When I first got into video editing, I had to use purely analogue technology - tape decks, cables, switches, mixers and stuff. My first digital editing system was so limited it was only barely useful - digitising analogue video required wierd unsupported hardware, my "top of the range" Pentium 133 CPU struggled under the load, the "huge" 1.6GB hard drive could only hold a few minutes of footage, and the Windows 95 OS was so flakey it hurt. Cameras now include their own digital output, CPUs are fast enough for basic preview, my 250GB drive can hold several hours, and Windows 2000 can go for days at a stretch without needing a reboot. Even low-cost editing software is usable for simple projects.

  But, the whole process is still slowed down by the need to continually read from and write to disk. The whole thing would be much smoother if all the footage for a project could be loaded into RAM, including multiple copies with different colour-correction settings, or at different resolutions. Sure, save it out to disk in idle moments in case the whole thing goes pear-shaped, but work entirely in RAM. To do this for a reasonable-sized amateur project might need something like 100GB of RAM

• Collaborative applications. We all work on the web these days. Massively multi-user web applications such as Google, eBay, Amazon, Slashdot are the bread-and-butter of IT knowledge work. But all these applications are hugely disk-bound. I don't know the details of the traffic and storage for these monsters, so let's take a look at one closer to my heart: JavaRanch.com, and in particular, its collaborative forums The Big Moose Saloon. The Ranch typically get around half a million unique visitors a month (page hit counts are much higher) and has a steadily growing collection of something like 500,000 messages at the moment. Currently this system uses CGI-based bulletin-board software; information has to be loaded from disk for every request and the poor old server is groaning under the strain. We've even had to turn off some of the more useful searching facilities because they crush the system completely. Now imagine how smooth and responsive this system could be if all the data was in RAM, with comprehensive indexing, and a broad instant-access cache of pre-rendered popular pages, threads and searches. As it stands, this system is just on the edge of what 32 bit addressing can support. We could probably fit it into a 4GB address space, but only because we just allow plain text messages which average out at around 1KB each. Any sort of multimedia or executable content (it's a board for programmers, but you can't upoad and share programs, d'oh!) would blow it out of the water. Power and responsiveness for this application would need RAM, and lots of it.

  And JavaRanch is just one of a whole galaxy of massively collaborative web applications. It's not even a particularly big one. Imagine if there were platforms and software available that would scale such communities without being limited by clumsy mechanical disk access.

And this is without considering things like all the millions of small-to-medium databases scattered around corporations and small businesses. I've done a lot of consulting, and the world of database design seems stuck with an obsolete model of hardware capabilities. Corporate departments proudly demonstrate their "huge" databases with "millions" of records, and the big, expensive, servers they live on. But do the sums. Even if each "record" is 1KB (in practice most seem to be much smaller, containing just a few dates or addresses), a million records is just 1GB. Even at the top end of 32 bit technology, the great many of these databases could fit entirely in RAM, - no messing about with expiry algorithms for cached data, paging strategies, and all that nonsense. If we move forward to 64 bit, multi-gigabyte memory, think how many databases could live and work entirely in RAM, with disk storage only there as a backup for when the power goes out.

The main problem now, though, is getting the programming languages and operating systems 64-bit-capable as soon as possible. I can't wait for massive-memory systems, but I want to use a familiar language like Java to program for them.