|
What It Means Continued from Flat vs. Segmented Address Spaces In "The Case for 32 Bits," published in the July/August 1992 issue of Microsoft Systems Journal, PC Magazine's contributing editor Charles Petzold presented a sparkling analysis of the performance differences between 16- and 32-bit code. His test-bed: two simple sorting programs written in C. Each used the popular bubble sort algorithm to sort an array of 32-bit integers. In one program, the array length was slightly less than 64K; in the other, the array was expanded so that it occupied slightly more than 64K. Both 16- and 32-bit versions of each program were compiled and then benchmarked. The results shouldn't be all that surprising. The 32-bit version of the program with the array under 64K ran 1.4 times faster than the 16-bit version (62 seconds versus 86 seconds), mostly because of the 32-bit code's greater efficiency in handling 32-bit integers. When the array size was bumped up beyond 64K, however, the 32-bit version ran a whopping five times faster--72 seconds for the 32-bit version compared with 366 seconds for the 16-bit version. Clearly, 32-bit code handles 32-bit variables and large arrays better than 16-bit code, which simply has to work harder to get the job done. Does this mean that a 32-bit word processor will perform five times faster than a 16-bit word processor? Not at all. Most of a word processor's time is spent waiting for user input, not performing intensive calculations. In addition, much of its data may be 8- or 16-bit, not 32-bit. Scrolling might be faster, but the bulk of the work involved in scrolling a page is performed by the accelerator on the video card, not the application. A large spreadsheet would probably recalc faster, but once again there are other factors to consider. The extent to which 32-bit code speeds up an application depends on the extent to which the application performs these kinds of tasks: moving data around in memory; adding, subtracting, multiplying, dividing, comparing, and in other ways manipulating 32-bit values; and handling large arrays. In coming months, you'll undoubtedly hear of some 32-bit apps that are slower than their 16-bit counterparts. It's certainly possible to write good 16-bit code that outperforms bad 32-bit code. But given the size of a typical application today, a well-written 32-bit application will almost always outperform a 16-bit implementation of the same. Published as Tutor in the 11/07/95 issue of PC Magazine. |
|
TOP |
Copyright (c) 1997 Ziff-Davis Inc. |