121 lines
7.4 KiB
Markdown
121 lines
7.4 KiB
Markdown
------------------------ --------------------------------- --------------------
|
||
[Previous](02-02.html) [Table of Contents](index.html) [Next](03-01.html)
|
||
------------------------ --------------------------------- --------------------
|
||
|
||
### The Flexible Mind {#Heading8}
|
||
|
||
Is the never-ending collection of information all there is to the
|
||
assembly optimization, then? Hardly. Knowledge is simply a necessary
|
||
base on which to build. Let’s take a moment to examine the objectives of
|
||
good assembly programming, and the remainder of the forces that act on
|
||
assembly optimization will fall into place.
|
||
|
||
Basically, there are only two possible objectives to high-performance
|
||
assembly programming: Given the requirements of the application, keep to
|
||
a minimum either the number of processor cycles the program takes to
|
||
run, or the number of bytes in the program, or some combination of both.
|
||
We’ll look at ways to achieve both objectives, but we’ll more often be
|
||
concerned with saving cycles than saving bytes, for the PC generally
|
||
offers relatively more memory than it does processing horsepower. In
|
||
fact, we’ll find that two-to-three times performance improvements *over
|
||
already tight assembly code* are often possible if we’re willing to
|
||
spend additional bytes in order to save cycles. It’s not always
|
||
desirable to use such techniques to speed up code, due to the heavy
|
||
memory requirements—but it is almost always *possible*.
|
||
|
||
You will notice that my short list of objectives for high-performance
|
||
assembly programming does not include traditional objectives such as
|
||
easy maintenance and speed of development. Those are indeed important
|
||
considerations—to persons and companies that develop and distribute
|
||
software. People who actually *buy* software, on the other hand, care
|
||
only about how well that software performs, not how it was developed nor
|
||
how it is maintained. These days, developers spend so much time focusing
|
||
on such admittedly important issues as code maintainability and
|
||
reusability, source code control, choice of development environment, and
|
||
the like that they often forget rule \#1: From the user’s perspective,
|
||
*performance is fundamental*.
|
||
|
||
------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||
 *Comment your code, design it carefully, and write non-time-critical portions in a high-level language, if you wish—but when you write the portions that interact with the user and/or affect response time, performance must be your paramount objective, and assembly is the path to that goal*.
|
||
------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||
|
||
Knowledge of the sort described earlier is absolutely essential to
|
||
fulfilling either of the objectives of assembly programming. What that
|
||
knowledge doesn’t do by itself is meet the need to write code that both
|
||
performs to the requirements of the application at hand and also
|
||
operates as efficiently as possible in the PC environment. Knowledge
|
||
makes that possible, but your programming instincts make it happen. And
|
||
it is that intuitive, on-the-fly integration of a program specification
|
||
and a sea of facts about the PC that is the heart of the Zen-class
|
||
assembly optimization.
|
||
|
||
As with Zen of any sort, mastering that Zen of assembly language is more
|
||
a matter of learning than of being taught. You will have to find your
|
||
own path of learning, although I will start you on your way with this
|
||
book. The subtle facts and examples I provide will help you gain the
|
||
necessary experience, but you must continue the journey on your own.
|
||
Each program you create will expand your programming horizons and
|
||
increase the options available to you in meeting the next challenge. The
|
||
ability of your mind to find surprising new and better ways to craft
|
||
superior code from a concept—the flexible mind, if you will—is the
|
||
linchpin of good assembler code, and you will develop this skill only by
|
||
doing.
|
||
|
||
Never underestimate the importance of the flexible mind. Good assembly
|
||
code is better than good compiled code. Many people would have you
|
||
believe otherwise, but they’re wrong. That doesn’t mean that high-level
|
||
languages are useless; far from it. High-level languages are the best
|
||
choice for the majority of programmers, and for the bulk of the code of
|
||
most applications. When the *best* code—the fastest or smallest code
|
||
possible—is needed, though, assembly is the only way to go.
|
||
|
||
Simple logic dictates that no compiler can know as much about what a
|
||
piece of code needs to do or adapt as well to those needs as the person
|
||
who wrote the code. Given that superior information and adaptability, an
|
||
assembly language programmer can generate better code than a compiler,
|
||
all the more so given that compilers are constrained by the limitations
|
||
of high-level languages and by the process of transformation from
|
||
high-level to machine language. Consequently, carefully optimized
|
||
assembly is not just the language of choice but the *only* choice for
|
||
the 1percent to 10 percent of code—usually consisting of small,
|
||
well-defined subroutines—that determines overall program performance,
|
||
and it is the only choice for code that must be as compact as possible,
|
||
as well. In the run-of-the-mill, non-time-critical portions of your
|
||
programs, it makes no sense to waste time and effort on writing
|
||
optimized assembly code—concentrate your efforts on loops and the like
|
||
instead; but in those areas where you need the finest code quality,
|
||
accept no substitutes.
|
||
|
||
Note that I said that an assembly programmer *can* generate better code
|
||
than a compiler, not *will* generate better code. While it is true that
|
||
good assembly code is better than good compiled code, it is also true
|
||
that bad assembly code is often much worse than bad compiled code; since
|
||
the assembly programmer has so much control over the program, he or she
|
||
has virtually unlimited opportunities to waste cycles and bytes. The
|
||
sword cuts both ways, and good assembly code requires more, not less,
|
||
forethought and planning than good code written in a high-level
|
||
language.
|
||
|
||
The gist of all this is simply that good assembly programming is done in
|
||
the context of a solid overall framework unique to each program, and the
|
||
flexible mind is the key to creating that framework and holding it
|
||
together.
|
||
|
||
#### Where to Begin? {#Heading9}
|
||
|
||
To summarize, the skill of assembly language optimization is a
|
||
combination of knowledge, perspective, and a way of thought that makes
|
||
possible the genesis of absolutely the fastest or the smallest code.
|
||
With that in mind, what should the first step be? Development of the
|
||
flexible mind is an obvious step. Still, the flexible mind is no better
|
||
than the knowledge at its disposal. The first step in the journey toward
|
||
mastering optimization at that exalted level, then, would seem to be
|
||
learning how to learn.
|
||
|
||
------------------------ --------------------------------- --------------------
|
||
[Previous](02-02.html) [Table of Contents](index.html) [Next](03-01.html)
|
||
------------------------ --------------------------------- --------------------
|
||
|
||
* * * * *
|
||
|
||
Graphics Programming Black Book © 2001 Michael Abrash
|