From 32-Bit to 64-Bit: Why Software Development Is Lagging Hardware Improvements

Why are you using 32-bit software on your 64-bit computer? If you just bought a top-of-the-line Sony BRAVIA 52″ 1080p 120Hz Flat-Panel LCD HDTV for $2,500, would you use a rabbit-ears antenna for your TV signal? I don’t think so!

Even though 64-bit software for UNIX goes back decades, mass availability and adoption of 64-bit operating systems and applications been slow. In theory, if you run 64-bit software on a 64-bit CPU-powered PC, you should get better performance. In practice, it’s not so clear cut. A 64-bit program that’s not optimized for a 64-bit processor can actually run worse than its 32-bit twin working on either 32- or 64-bit Windows Vista.

To make use of 64-bit’s performance and features, both the operating system and application must be optimized for the new processor. However, many developers see 32-bit software as being “good enough.” They rely on the processor’s improved speed to disguise the 32-bit code’s inherent inefficiency on a 64-bit processor. That inefficiency may not be trivial, since every call to 32-bit code must be translated to 64-bit code before it can run. For example, on Windows Vista 64-bit, 32-bit applications must be “thunked” via the WoW64 (Windows on Windows) subsystem to run. Similar methods are used in other operating systems.

By avoiding this translation process, any well-written and optimized 64-bit program should run faster. In addition, any application that requires access to huge amounts of memory, such as a database or simulation, should run more efficiently in 64-bit environments.

Of course, developers may encounter roadblocks before they even need to worry about optimizing their own code for 64-bit architectures. Jerry Young, a .NET Developer at American Processing says, “There are some people stuck in 32-bit land.” For example, says Young, Microsoft’s IIS (Internet Information Server) Web server can have issues with Windows Server 2003 because IIS doesn’t support mixed modes. “Specifically, I had a C# application installed on a 64-bit Windows 2003 installation and IIS was set up to run in 64-bit. The problem was: I had a legacy 32-bit C++ DLL, and it wouldn’t work,” he explains.

But integration issues aren’t the only reasons why some developers aren’t migrating their applications to 64-bit.

Karl Ginter, CEO at Cognition IP Solutions, observes that some developers don’t care because their language or development environment (such as Java, Flash or Perl) deals with all the underlying issues (or fails to). Ginter says, “64-bit doesn’t appear to help that much in these cases. [The code] runs a bit faster, but most machines aren’t even close to CPU-bound.” Ginter adds, “[That’s] why virtualization has taken off.”

Ginter believes that the 32- to 64-bit switchover is pretty easy, but often there is no real compelling reason to change. “Granted, there are specific applications where 64-bit makes sense,” he admits, such as with large databases and virtualization servers. But he adds, “I think a wholesale switch to 64-bit will likely occur only when 64-bit is the default instead of 32-bit. In my opinion, it’s a solution begging a problem for 80 percent of the world.”

Brian Masinick, a project manager at Fidelity Investments and noted Linux enthusiast, agrees. “I have reservations and concerns about using 64-bit PC operating systems, even in the Linux space, where it most certainly can be done. Tools are there, plenty of applications are there, but getting stuff like Flash players—though those, too, can be done—have an ugly reputation for being problematic.”

In short, these programmers believe that we’re not moving to 64-bits with any speed because the technical enhancements are not yet perceived as a necessity. Masnick added, “I ran 64-bit all the time on my Digital UNIX AlphaStation [which ran Tru64 Unix], but until I can get a clean, inexpensive system that works 100 percent, I am not terribly motivated to do so. What I have seems to work just fine for casual use, which is really all that I need at home most of the time.” For Masnik, 64-bit applications are “icing on a cake, if I could afford the cake.”

Of course, that all depends on where you’re standing. In the server world, 64-bits is often the better way to go. Jari Tavi, CEO at Hotelzon International, remembered participating in a software development project as an architect, when the team had a problem with a cellular network MSC (Mobile Switching Center). The MSC had scalability issues in certain business cases. “In the back-end system, we replaced a whole Oracle database with a memory-mapped sparse file with 64-bit addressing. We had 100 to 1,000 times improvement in performance. The core of the ‘replacement code’ was only around 300 lines of C. So, if you know what you’re doing the answer is yes, you can change things.”

Less dramatic, but still telling, was when Michael Tajmajer, a software developer for iGraphicsGroup.com moved a medium-sized Windows application (over a million lines of code) to 64-bit last year. Microsoft’s developer tools, such as Visual Studio 2008 with Vista x64, made this fairly easy, he says. “I had one module gain a 30 percent boost in performance due to the additional registers in x64 mode.”

With the right approach, Tavi adds, moving to 64-bit isn’t that much trouble for programmers. “Some of the vendors took a so-called ‘LP64’ approach, which I personally highly promote,” he says. To Tavi, LP64’s strengths—where int variables are 32 bits wide, but longs and pointers are 64 bits wide—are that well-written and well-behaving code requires minimal changes. “If you had problems with your application, in 99 percent of cases it was a bug—or at least bad programming—and fixing that improves the quality of the code,” he says. “With LP64, you will get almost unlimited memory and file addressing with zero programming cost and you can blow the 2G/4G limits etc. So it itself is cool!”

There are other 64-bit data models. With ILP64, all three data types are 64 bits wide; in LLP64, only long-longs are 64-bit. However, LP64 is broadly supported both in open-source and proprietary operating systems and compilers. Compilers for AIX, FreeBSD, HP, Linux, Mac OS X, Microsoft Visual C++, Solaris and IBM z/OS all support LP64.

Another big plus for 64-bit development, said Chris Browne, a database architect at Afilias Canada was the introduction of a 64-bit type to the C language. That’s important, Browne says, because C is frequently the underpinning for other languages. “[64-bit support] was officially added to C as part of C99, which has been percolating into C implementations over the last nine or so years, and hence into anything else implemented in C, such as operating systems, frameworks, other languages (Perl, Python, PHP and such), database implementations, and libraries and frameworks.”

Browne claims that developers who write write good, portable code frequently will find that the 64-bit version “just naturally works” when compiled with a compiler in which integers and pointers are 64 bits long.

So why, if that’s so easy, is it such a problem to find, say, 64-bit VPN (Virtual Private Network) clients or hardware drivers? Why aren’t more 64-bit programs and operating system available?

The answer is: It depends. Browne notes that “That’s probably more problematic on Windows, where a lot of internals are tied to very specific data representations. This is nothing new. There were huge problems in the transition between Windows 3.1 (which had a whole lot of 16-bit dependencies, since it was first deployed atop MS-DOS) and Win32. The shift between those ecosystems was from one with massive 16-bit-isms hard-coded into it, to another with equivalent 32-bit-isms hard-coded into it.”

While it isn’t as much trouble as it was then, Windows’ 64-bit versions still retain similar problems. Not all 64-bit operating systems, even if with the same name, work the same. Alexey Roytman, a software engineer at HyperRoll, notes that the Windows 64-bit that runs on Itanium is… different. “32-bit applications are running slow because of software emulation,” he says. “There are some issues with Microsoft command tools (the one you can get for free) with Itanium as cross-compilation.”

Browne continues, “On UNIX in contrast, [the code] tended to need to be portable across Solaris, HP/UX, AIX, DG/UX, SCO, IRIX—and I’m probably forgetting some—and the need for portability mandated a bit more delicate handling.” As a result, says Browne, developers porting from 16-bit to 32-bit applications led to those applications being nearly already portable to 64 bits.

Perhaps the single biggest reason we haven’t seen a mass migration from 32- to 64-bit operating systems and applications is because of the reason supplied by Shane O’Donnell, vice president of engineering at BlueStripe Software: “There’s no clear forcing function to kill off 32-bit work.” The way O’Donnell figures it, “The industry will shift when Microsoft stops producing 32-bit operating systems. It’s all about the operating systems and the lowest barrier to entry for the junior programmer.”

So, until the day comes when the lowest common denominator is 64-bits, it looks like we’re going to be continue to have to deal with 32-bit software, and its quirks, on our 64-bit systems: Whether we like it, need it, or want it.