113 lines
No EOL
6.2 KiB
Markdown
113 lines
No EOL
6.2 KiB
Markdown
*Part I* {align="center"}
|
|
--------
|
|
|
|
Chapter 1\
|
|
The Best Optimizer Is between Your Ears {#Heading1}
|
|
----------------------------------------
|
|
|
|
### The Human Element of Code Optimization {#Heading2}
|
|
|
|
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 that's going on, if you so wish.
|
|
|
|
As we'll 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 wouldn't be happier if they ran faster?
|
|
We're 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,
|
|
we're ecstatic—when 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 you're
|
|
willing to think past the obvious solution to unconventional but
|
|
potentially more fruitful approaches.
|
|
|
|
My point is simply this: PCs can work wonders. It's not easy coaxing
|
|
them into doing that, but it's rewarding—and it's sure as heck fun. In
|
|
this book, we're going to work some of those wonders, starting...
|
|
|
|
...now.
|
|
|
|
### Understanding High Performance {#Heading3}
|
|
|
|
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 doesn't say anything
|
|
about how the code was designed and written. What it does say is that
|
|
high-performance code shouldn't get in the user's way—and that's *all*.
|
|
|
|
That's 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. They're 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 doing—*and*
|
|
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 program's operation, your carefully optimized code will amount to one of mankind's least fruitful creations—a fast slow program*.
|
|
------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
|
|
"What's a fast slow program?" you ask. That's a good question, and a
|
|
brief (true) story is perhaps the best answer.
|
|
|
|
#### When Fast Isn't Fast {#Heading4}
|
|
|
|
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 duel—and 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. What's 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, you're wasting the
|
|
optimization, much as Irwin did. Particularly in assembly, you'll find
|
|
that without proper up-front design and everything else that goes into
|
|
high-performance design, you'll waste considerable effort and time on
|
|
making an inherently slow program as fast as possible—which is still
|
|
slow—when you could easily have improved performance a great deal more
|
|
with just a little thought. As we'll see, handcrafted assembly language
|
|
and optimizing compilers matter, but less than you might think, in the
|
|
grand scheme of things—and they scarcely matter at all unless they're
|
|
used in the context of a good design and a thorough understanding of
|
|
both the task at hand and the PC. |