|Previous||Table of Contents||Next|
This book is devoted to a topic near and dear to my heart: writing software that pushes PCs to the limit. Given run-of-the-mill software, PCs run like the 97-pound-weakling minicomputers they are. Give them the proper care, however, and those ugly boxes are capable of miracles. The key is this: Only on microcomputers do you have the run of the whole machine, without layers of operating systems, drivers, and the like getting in the way. You can do anything you want, and you can understand everything thats going on, if you so wish.
As well see shortly, you should indeed so wish.
Is performance still an issue in this era of cheap 486 computers and super-fast Pentium computers? You bet. How many programs that you use really run so fast that you wouldnt be happier if they ran faster? Were so used to slow software that when a compile-and-link sequence that took two minutes on a PC takes just ten seconds on a 486 computer, were ecstaticwhen in truth we should be settling for nothing less than instantaneous response.
Impossible, you say? Not with the proper design, including incremental compilation and linking, use of extended and/or expanded memory, and well-crafted code. PCs can do just about anything you can imagine (with a few obvious exceptions, such as applications involving super-computer-class number-crunching) if you believe that it can be done, if you understand the computer inside and out, and if youre willing to think past the obvious solution to unconventional but potentially more fruitful approaches.
My point is simply this: PCs can work wonders. Its not easy coaxing them into doing that, but its rewardingand its sure as heck fun. In this book, were going to work some of those wonders, starting...
Before we can create high-performance code, we must understand what high performance is. The objective (not always attained) in creating high-performance software is to make the software able to carry out its appointed tasks so rapidly that it responds instantaneously, as far as the user is concerned. In other words, high-performance code should ideally run so fast that any further improvement in the code would be pointless.
Notice that the above definition most emphatically does not say anything about making the software as fast as possible. It also does not say anything about using assembly language, or an optimizing compiler, or, for that matter, a compiler at all. It also doesnt say anything about how the code was designed and written. What it does say is that high-performance code shouldnt get in the users wayand thats all.
Thats an important distinction, because all too many programmers think that assembly language, or the right compiler, or a particular high-level language, or a certain design approach is the answer to creating high-performance code. Theyre not, any more than choosing a certain set of tools is the key to building a house. You do indeed need tools to build a house, but any of many sets of tools will do. You also need a blueprint, an understanding of everything that goes into a house, and the ability to use the tools.
Likewise, high-performance programming requires a clear understanding of the purpose of the software being built, an overall program design, algorithms for implementing particular tasks, an understanding of what the computer can do and of what all relevant software is doingand solid programming skills, preferably using an optimizing compiler or assembly language. The optimization at the end is just the finishing touch, however.
|Without good design, good algorithms, and complete understanding of the programs operation, your carefully optimized code will amount to one of mankinds least fruitful creationsa fast slow program.|
Whats a fast slow program? you ask. Thats a good question, and a brief (true) story is perhaps the best answer.
In the early 1970s, as the first hand-held calculators were hitting the market, I knew a fellow named Irwin. He was a good student, and was planning to be an engineer. Being an engineer back then meant knowing how to use a slide rule, and Irwin could jockey a slipstick with the best of them. In fact, he was so good that he challenged a fellow with a calculator to a dueland won, becoming a local legend in the process.
When you get right down to it, though, Irwin was spitting into the wind. In a few short years his hard-earned slipstick skills would be worthless, and the entire discipline would be essentially wiped from the face of the earth. Whats more, anyone with half a brain could see that changeover coming. Irwin had basically wasted the considerable effort and time he had spent optimizing his soon-to-be-obsolete skills.
What does all this have to do with programming? Plenty. When you spend time optimizing poorly-designed assembly code, or when you count on an optimizing compiler to make your code fast, youre wasting the optimization, much as Irwin did. Particularly in assembly, youll find that without proper up-front design and everything else that goes into high-performance design, youll waste considerable effort and time on making an inherently slow program as fast as possiblewhich is still slowwhen you could easily have improved performance a great deal more with just a little thought. As well see, handcrafted assembly language and optimizing compilers matter, but less than you might think, in the grand scheme of thingsand they scarcely matter at all unless theyre used in the context of a good design and a thorough understanding of both the task at hand and the PC.
|Previous||Table of Contents||Next|