Misc/abrash-black-book
Watch
1
0
Fork
You've already forked abrash-black-book
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Normal quotes

Browse source
This commit is contained in:
James Gregory 2013-12-30 18:34:31 +11:00
commit 18011c595a
352 changed files with 6040 additions and 6040 deletions
Download patch file Download diff file Expand all files Collapse all files

16
02-01.md
View file

@ -9,17 +9,17 @@ Chapter 2\
### The Unique Nature of Assembly Language Optimization {#Heading2}
As I showed in the previous chapter, optimization is by no means always
a matter of “dropping into assembly.” In fact, in performance tuning
a matter of "dropping into assembly." In fact, in performance tuning
high-level language code, assembly should be used rarely, and then only
after you’ve made sure a badly chosen or clumsily implemented algorithm
isn’t eating you alive. Certainly if you use assembly at all, make
after you've made sure a badly chosen or clumsily implemented algorithm
isn't eating you alive. Certainly if you use assembly at all, make
absolutely sure you use it *right*. The potential of assembly code to
run *slowly* is poorly understood by a lot of people, but that potential
is great, especially in the hands of the ignorant.
Truly great optimization, however, happens *only* at the assembly level,
and it happens in response to a set of dynamics that is totally
different from that governing C/C++ or Pascal optimization. I’ll be
different from that governing C/C++ or Pascal optimization. I'll be
speaking of assembly-level optimization time and again in this book, but
when I do, I think it will be helpful if you have a grasp of those
assembly specific dynamics.
@ -32,7 +32,7 @@ Some time ago, I was asked to work over a critical assembly subroutine
in order to make it run as fast as possible. The task of the subroutine
was to construct a nibble out of four bits read from different bytes,
rotating and combining the bits so that they ultimately ended up neatly
aligned in bits 3-0 of a single byte. (In case you’re curious, the
aligned in bits 3-0 of a single byte. (In case you're curious, the
object was to construct a 16-color pixel from bits scattered over 4
bytes.) I examined the subroutine line by line, saving a cycle here and
a cycle there, until the code truly seemed to be optimized. When I was
@ -47,7 +47,7 @@ done, the key part of the code looked something like this:
dec dx ;count down the number of bits
jnz LoopTop ;process the next bit, if any
Now, it’s hard to write code that’s much faster than seven instructions,
Now, it's hard to write code that's much faster than seven instructions,
only one of which accesses memory, and most programmers would have
called it a day at this point. Still, something bothered me, so I spent
a bit of time going over the code again. Suddenly, the answer struck
@ -76,9 +76,9 @@ performed just once, rather than four times. While the code may not look
much different from the original, and in fact still contains exactly the
same number of instructions, the performance of the entire subroutine
improved by about 10 percent from just this one change. (Incidentally,
that wasn’t the end of the optimization; I eliminated the **DEC** and
that wasn't the end of the optimization; I eliminated the **DEC** and
**JNJ** instructions by expanding the four iterations of the loop—but
that’s a tale for another chapter.)
that's a tale for another chapter.)
The point is this: To write truly superior assembly programs, you need
to know what the various instructions do and which instructions execute