The transition from 16-bit Windows software to 32-bit Windows software over a decade ago was an event that future archeologists will no doubt write papers about and bore people at parties with until they all make up excuses about having forgotten to hypnotize their ferrets and leave. Admittedly, archeologists get excited about the damnedest things.
It’s been our experience that neither archeologists nor most of the people who use Windows software actually know why 32-bit applications are preferable. This is arguably as it should be – well-written software should allow its users to do whatever they bought the beast for and never concern themselves with that’s going on under the hood.
The down side to this observation is that many users who were delighted with 32-bit applications back in the day have come to the conclusion that if 32 bits are good, 64 bits would be better.
Depending upon how the digits fall, quite the opposite may well be true.
Understanding this issue will entail a brief digression into the turgid alternate universe of funny arithmetic and uncomfortably large numbers. Grab something solid.
The Big Box
When one speaks of 16-bit software, 32-bit software and the oft-mentioned but rarely understood 64-bit software, what’s really at issue is the processor that will run the software in question. The number of bits associated with a processor determines the largest number said processor can work with as a single object, or what’s called the “register width” of the processor.
A 16-bit processor can work with numbers that are sixteen bits wide, or numbers no greater than 216, or 65535.
A 32-bit processor can work with numbers that are 32 bits wide, or numbers no greater than 232, or 4,294,967,296.
A 64-bit processor can work with numbers that are 64 bits wide, or numbers no greater than 264… which is a number having more digits than my calculator can manage.
I hasten to add that software running on these processors is often called upon to deal with numbers larger than can be managed by a single register. Doing so is possible – it’s just slower.
One of the fundamental limitations inherent in processors of specific bit sizes is the amount of memory they can access, as memory addresses are stored in processor registers. A 32-bit processor can address a maximum of four gigabytes of memory. A few years ago, this was more memory than anyone needed or could afford. At the moment, some cell phones are sold with more than four gigabytes of memory.
A 64-bit processor can address up to four petabytes of memory. A petabyte is 1000 terrabytes. A terabyte is a thousand gigabytes. It probably need not be said that your computer doesn’t have quite enough memory slots to plug in four petabytes of memory, or anything like it.
Windows is available in 32- and 64-bit editions, to run on 32- and 64-bit processors, respectively. The 64-bit editions of Windows will run both 32- and 64-bit applications. For practical purposes, a 32-bit Windows application won’t care whether it’s running on 32- or 64-bit hardware. Unless it’s particularly sneaky, it won’t even know.
There are unquestionably very good reasons for using 64-bit software… pretty much all of them involving the manipulation of very, very large memory objects. Working with lots of digital video, for example, is a task that fairly shrieks for a true 64-bit environment… and a very expensive computer.
Software with smaller memory footprints derives somewhat less benefit from being a true 64-bit application. Actually, make that no detectable benefit at all. An application that will never require anything approaching four gigabytes of memory won’t run any better, faster or smarter if it’s compiled as true 64-bit software.
There is, in addition, a decided down side to 64-bit applications. All the integers, numbers, pointers and other machine-related objects therein are twice the size of comparable objects in 32-bit software. A machine register-size object in 32-bit software requires four bytes. This swells to eight bytes in a 64-bit environment. In that complex software consists of innumerable integers, numbers, pointers and other machine-related objects, this “object swell” in 64-bit software can result in 64-bit applications requiring substantially more memory than their 32-bit cousins.
Memory from Mars
If your computer has a significant fraction of four petabytes of memory available to it, the extra memory required to run 64-bit software will trouble it not. If, on the other hand, your computer was built on the planet Earth rather than beamed in from a technologically-advanced alien civilization, 64-bit software is a lot more likely to bump up against its memory limitations than 32-bit software would do.
When applications running under Windows start exceeding the bounds of good taste and available memory, Windows will “spill” some of its memory objects to your hard drive. This means that it will look for parts of itself and of the other applications running under it that it doesn’t think are needed right at the moment, send them to temporary disk files and free up their memory. When the spilled objects are required, it will recover them from your hard drive. The catch in this process is that it’s grotesquely slow compared to processes that exist exclusively in real memory.
All other things being equal, software that hogs more memory increases the likelihood of Windows spilling objects to disk. As such, when it’s running on a real-world computer with a finite amount of memory, large 64-bit software is typically slower than comparable 32-bit software.
If you need to manage a lot of digital video, or other data objects of impressive enormity, you’ll have to live with this. Applications of more modest requirements are actually better off as 32-bit software for the moment.
We’re asked on occasion whether we intend to offer 64-bit versions of the Alchemy Mindworks applications, most notably Graphic Workshop Professional. As of this writing, it’s something of an open question. While a 64-bit build would unquestionably satisfy those of our users who like large numbers, it wouldn’t run any better than the 32-bit build, and in some cases, it would be slower. None of our software calls for anything like four gigabytes of memory.
Creating inefficacious software with nice packaging is arguably not what we’re about.