Well, then, how are we going to improve our design? Before we can do that, we have to understand what’s wrong with the current design.
-Know the Territory
+Know the Territory
Just why is Listing 1.1 so slow? In a word: overhead. The C library implements the read() function by calling DOS to read the desired number of bytes. (I figured this out by watching the code execute with a debugger, but you can buy library source code from both Microsoft and Borland.) That means that Listing 1.1 (and Listing 1.3 as well) executes one DOS function per byte processed—and DOS functions, especially this one, come with a lot of overhead.
@@ -278,16 +281,20 @@ _ChecksumFileendpListing 1.4 is similar to Listing 1.1, but uses fopen() and getc() (rather than open() and read()) to access the file being checksummed. The results confirm our theories splendidly, and validate our new design. As shown in Table 1.1, Listing 1.4 runs more than an order of magnitude faster than even the assembly version of Listing 1.1, even though Listing 1.1 and Listing 1.4 look almost the same. To the casual observer, read() and getc() would seem slightly different but pretty much interchangeable, and yet in this application the performance difference between the two is about the same as that between a 4.77 MHz PC and a 16 MHz 386.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
 |
@@ -77,7 +80,7 @@ main(int argc, char *argv[]) {
}
-
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
The third reason is often fallacious. C library functions are not always written in assembly, nor are they always particularly well-optimized. (In fact, they’re often written for portability, which has nothing to do with optimization.) What’s more, they’re general-purpose functions, and often can be outperformed by well-but-not- brilliantly-written code that is well-matched to a specific task. As an example, consider Listing 1.5, which uses internal buffering to handle blocks of bytes at a time. Table 1.1 shows that Listing 1.5 is 2.5 to 4 times faster than Listing 1.4 (and as much as 49 times faster than Listing 1.1!), even though it uses no assembly at all.
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
LISTING 1.7 L1-7.ASM
; Assembler subroutine to perform a 16-bit checksum on a block of @@ -103,22 +106,26 @@ _ChecksumChunkendpOptimization only matters after you’ve done your part on the program design end. Consider the ratios on the vertical axis of Table 1.1, which show that optimization is almost totally wasted in the checksumming application without an efficient design. Optimization is no panacea. Table 1.1 shows a two-times improvement from optimization—and a 50-times-plus improvement from redesign. The longstanding debate about which C compiler optimizes code best doesn’t matter quite so much in light of Table 1.1, does it? Your organic optimizer matters much more than your compiler’s optimizer, and there’s always assembly for those usually small sections of code where performance really matters.
-Where We’re Going
+Where We’re Going
This chapter has presented a quick step-by-step overview of the design process. I’m not claiming that this is the only way to create high-performance code; it’s just an approach that works for me. Create code however you want, but never forget that design matters more than detailed optimization. Never stop looking for inventive ways to boost performance—and never waste time speeding up code that doesn’t need to be sped up.
I’m going to focus on specific ways to create high-performance code from now on. In Chapter 5, we’ll continue to look at restartable blocks and internal buffering, in the form of a program that searches files for text strings.
--
diff --git a/02-01.html b/02-01.html index 9807c63..01665b0 100644 --- a/02-01.html +++ b/02-01.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
Chapter 2
@@ -88,16 +91,20 @@ LoopTop:
A World ApartTo understand why this is so, consider how a program gets written. A programmer examines the requirements of an application, designs a solution at some level of abstraction, and then makes that design come alive in a code implementation. If not handled properly, the transformation that takes place between conception and implementation can reduce performance tremendously; for example, a programmer who implements a routine to search a list of 100,000 sorted items with a linear rather than binary search will end up with a disappointingly slow program.
--
diff --git a/02-02.html b/02-02.html index 0cf5f7d..3c315bb 100644 --- a/02-02.html +++ b/02-02.html @@ -1,5 +1,4 @@ - + @@ -19,18 +18,22 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + - -
Transformation Inefficiencies
+Transformation Inefficiencies
No matter how well an implementation is derived from the corresponding design, however, high-level languages like C/C++ and Pascal inevitably introduce additional transformation inefficiencies, as shown in Figure 2.1.
@@ -50,11 +53,11 @@The key, of course, is the programmer, since in assembly the programmer must essentially perform the transformation from the application specification to machine language entirely on his or her own. (The assembler merely handles the direct translation from assembly to machine language.)
-Self-Reliance
+Self-Reliance
The first part of assembly language optimization, then, is self. An assembler is nothing more than a tool to let you design machine-language programs without having to think in hexadecimal codes. So assembly language programmers—unlike all other programmers—must take full responsibility for the quality of their code. Since assemblers provide little help at any level higher than the generation of machine language, the assembly programmer must be capable both of coding any programming construct directly and of controlling the PC at the lowest practical level—the operating system, the BIOS, even the hardware where necessary. High-level languages handle most of this transparently to the programmer, but in assembly everything is fair—and necessary—game, which brings us to another aspect of assembly optimization: knowledge.
-Knowledge
+Knowledge
In the PC world, you can never have enough knowledge, and every item you add to your store will make your programs better. Thorough familiarity with both the operating system APIs and BIOS interfaces is important; since those interfaces are well-documented and reasonably straightforward, my advice is to get a good book or two and bring yourself up to speed. Similarly, familiarity with the PC hardware is required. While that topic covers a lot of ground—display adapters, keyboards, serial ports, printer ports, timer and DMA channels, memory organization, and more—most of the hardware is well-documented, and articles about programming major hardware components appear frequently in the literature, so this sort of knowledge can be acquired readily enough.
@@ -68,16 +71,20 @@
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
The Flexible Mind
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.
@@ -58,20 +61,24 @@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?
+Where to Begin?
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 | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Chapter 3
Assume Nothing
@@ -69,16 +72,20 @@
Listing 3.1 shows 8253-based timer software, consisting of three subroutines: ZTimerOn, ZTimerOff, and ZTimerReport. For the remainder of this book, I’ll refer to these routines collectively as the “Zen timer.” C-callable versions of the two precision Zen timers are presented in Chapter K on the companion CD-ROM.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
LISTING 3.1 PZTIMER.ASM
; The precision Zen timer (PZTIMER.ASM)
@@ -473,16 +476,20 @@ Code ends
end
- | Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
The Zen Timer Is a Means, Not an End
+The Zen Timer Is a Means, Not an End
We’re going to spend the rest of this chapter seeing what the Zen timer can do, examining how it works, and learning how to use it. I’ll be using the Zen timer again and again over the course of this book, so it’s essential that you learn what the Zen timer can do and how to use it. On the other hand, it is by no means essential that you understand exactly how the Zen timer works. (Interesting, yes; essential, no.)
In other words, the Zen timer isn’t really part of the knowledge we seek; rather, it’s one tool with which we’ll acquire that knowledge. Consequently, you shouldn’t worry if you don’t fully grasp the inner workings of the Zen timer. Instead, focus on learning how to use it, and you’ll be on the right road.
-Starting the Zen Timer
+Starting the Zen Timer
ZTimerOn is called at the start of a segment of code to be timed. ZTimerOn saves the context of the calling code, disables interrupts, sets timer 0 of the 8253 to mode 2 (divide-by-N mode), sets the initial timer count to 0, restores the context of the calling code, and returns. (I’d like to note that while Intel’s documentation for the 8253 seems to indicate that a timer won’t reset to 0 until it finishes counting down, in actual practice, timers seem to reset to 0 as soon as they’re loaded.)
@@ -67,16 +70,20 @@Why not use timer 2 instead of timer 0 for precision timing? After all, timer 2 has a programmable gate input and isn’t used for anything but sound generation. The problem with timer 2 is that its output can’t generate an interrupt; in fact, timer 2 can’t do anything but drive the speaker. We need the interrupt generated by the output of timer 0 to tell us when the count has overflowed, and we will see shortly that the timer interrupt also makes it possible to time much longer periods than the Zen timer shown in Listing 3.1 supports.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
In fact, the Zen timer shown in Listing 3.1 can only time intervals of up to about 54 ms in length, since that is the period of time that can be measured by timer 0 before its count turns over and repeats. fifty-four ms may not seem like a very long time, but even a CPU as slow as the 8088 can perform more than 1,000 divides in 54 ms, and division is the single instruction that the 8088 performs most slowly. If a measured period turns out to be longer than 54 ms (that is, if timer 0 has counted down and turned over), the Zen timer will display a message to that effect. A long-period Zen timer for use in such cases will be presented later in this chapter.
The Zen timer determines whether timer 0 has turned over by checking to see whether an IRQ0 interrupt is pending. (Remember, interrupts are off while the Zen timer runs, so the timer interrupt cannot be recognized until the Zen timer stops and enables interrupts.) If an IRQ0 interrupt is pending, then timer 0 has turned over and generated a timer interrupt. Recall that ZTimerOn initially sets timer 0 to 0, in order to allow for the longest possible period—about 54 ms—before timer 0 reaches 0 and generates the timer interrupt.
@@ -70,16 +73,20 @@You may well want to devise still other approaches better suited to your needs than those I’ve presented. Go to it! I’ve just thrown out a few possibilities to get you started.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Notes on the Zen Timer
The Zen timer subroutines are designed to be near-called from assembly language code running in the public segment Code. The Zen timer subroutines can, however, be called from any assembly or high-level language code that generates OBJ files that are compatible with the Microsoft linker, simply by modifying the segment that the timer code runs in to match the segment used by the code being timed, or by changing the Zen timer routines to far procedures and making far calls to the Zen timer code from the code being timed, as discussed at the end of this chapter. All three subroutines preserve all registers and all flags except the interrupt flag, so calls to these routines are transparent to the calling code.
@@ -121,16 +124,20 @@ Skip:It’s worth noting that Listing 3.3 begins by jumping around the memory variable MemVar. This approach lets us avoid reproducing Listing 3.2 in its entirety for each code fragment we want to measure; by defining any needed data right in the code segment and jumping around that data, each listing becomes self-contained and can be plugged directly into Listing 3.2 as TESTCODE. Listing 3.2 sets DS equal to CS before doing anything else precisely so that data can be embedded in code fragments being timed. Note that only after the initial jump is performed in Listing 3.3 is the Zen timer started, since we don’t want to include the execution time of start-up code in the timing interval. That’s why the calls to ZTimerOn and ZTimerOff are in TESTCODE, not in PZTEST.ASM; this way, we have full control over which portion of TESTCODE is timed, and we can keep set-up code and the like out of the timing interval.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Listing 3.3 is used by naming it TESTCODE, assembling both Listing 3.2 (which includes TESTCODE) and Listing 3.1 with TASM or MASM, and linking the two resulting OBJ files together by way of the Borland orMicrosoft linker. Listing 3.4 shows a batch file, PZTIME.BAT, which does all that; when run, this batch file generates and runs the executable file PZTEST.EXE. PZTIME.BAT (Listing 3.4) assumes that the file PZTIMER.ASM contains Listing 3.1, and the file PZTEST.ASM contains Listing 3.2. The command-line parameter to PZTIME.BAT is the name of the file to be copied to TESTCODE and included into PZTEST.ASM. (Note that Turbo Assembler can be substituted for MASM by replacing “masm” with “tasm” and “link” with “tlink” in Listing 3.4. The same is true of Listing 3.7.)
LISTING 3.4 PZTIME.BAT
@@ -123,16 +126,20 @@ pztime <filename>You should not use the long-period Zen timer to time code that requires interrupts to be disabled for more than 54 ms at a stretch during the timing interval, since when interrupts are disabled the long-period Zen timer is subject to the same 54 ms maximum measurement time as the precision Zen timer.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
While permitting the timer interrupt to occur allows long intervals to be timed, that same interrupt makes the long-period Zen timer less accurate than the precision Zen timer, since the time the BIOS spends handling timer interrupts during the timing interval is included in the time measured by the long-period timer. Likewise, any other interrupts that occur during the timing interval, most notably keyboard and mouse interrupts, will increase the measured time.
The long-period Zen timer has some of the same effects on the system time as does the precision Zen timer, so it’s a good idea to reboot the system after a session with the long-period Zen timer. The long-period Zen timer does not, however, have the same potential for introducing major inaccuracy into the system clock time during a single timing run since it leaves interrupts enabled and therefore allows the system clock to update normally.
-Stopping the Clock
+Stopping the Clock
There’s a potential problem with the long-period Zen timer. The problem is this: In order to measure times longer than 54 ms, we must maintain not one but two timing components, the timer 0 count and the BIOS time-of-day count. The time-of-day count measures the passage of 54.9 ms intervals, while the timer 0 count measures time within those 54.9 ms intervals. We need to read the two time components simultaneously in order to get a clean reading. Otherwise, we may read the timer count just before it turns over and generates an interrupt, then read the BIOS time-of-day count just after the interrupt has occurred and caused the time-of-day count to turn over, with a resulting 54 ms measurement inaccuracy. (The opposite sequence—reading the time-of-day count and then the timer count—can result in a 54 ms inaccuracy in the other direction.)
@@ -684,16 +687,20 @@ Code ends end -| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Moreover, because it uses an undocumented feature, the timer-stop approach could conceivably cause erratic 8253 operation, which could in turn seriously affect your computer’s operation until the next reboot. In non-8253-compatible systems, I’ve observed not only wildly incorrect timing results, but also failure of a diskette drive to operate properly after the long-period Zen timer with PS2 set to 0 has run, so be alert for signs of trouble if you do set PS2 to 0.
Rebooting should clear up any timer-related problems of the sort described above. (This gives us another reason to reboot at the end of each code-timing session.) You should immediately reboot and set the PS2 equate to 1 if you get erratic or obviously incorrect results with the long-period Zen timer when PS2 is set to 0. If you want to set PS2 to 0, it would be a good idea to time a few of the listings in this book with PS2 set first to 1 and then to 0, to make sure that the results match. If they’re consistently different, you should set PS2 to 1.
@@ -110,16 +113,20 @@ Code endsAs with the precision Zen timer, the program in Listing 3.6 is used by naming the file containing the code to be timed TESTCODE, then assembling both Listing 3.6 and Listing 3.5 with MASM or TASM and linking the two files together by way of the Microsoft or Borland linker. Listing 3.7 shows a batch file, named LZTIME.BAT, which does all of the above, generating and running the executable file LZTEST.EXE. LZTIME.BAT assumes that the file LZTIMER.ASM contains Listing 3.5 and the file LZTEST.ASM contains Listing 3.6.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
LISTING 3.7 LZTIME.BAT
echo off @@ -146,16 +149,20 @@ lztime lst3-8.asm extern “C” ZTimerOn(void);-
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
when declaring the timer routines extern, so that name-mangling doesn’t occur, and the linker can find the routines’ C-style names.)
That’s all it takes; after doing this, you’ll be able to use the Zen timer from C, as, for example, in:
@@ -50,7 +53,7 @@ ZTimerReport();The full listings for the C-callable Zen timers are presented in Chapter K on the companion CD-ROM.
-Watch Out for Optimizing Assemblers!
+Watch Out for Optimizing Assemblers!
One important safety tip when modifying the Zen timer for use with large code model C code: Watch out for optimizing assemblers! TASM actually replaces
@@ -76,28 +79,32 @@ call near ptr ReferenceZTimerOnI’ve tested the changes shown in Figures 3.2 and 3.3 with TASM and Borland C++ 4.0, and also with the latest MASM and Microsoft C/C++ compiler.
-Further Reading
+Further Reading
For those of you who wish to pursue the mechanics of code measurement further, one good article about measuring code performance with the 8253 timer is “Programming Insight: High-Performance Software Analysis on the IBM PC,” by Byron Sheppard, which appeared in the January, 1987 issue of Byte. For complete if somewhat cryptic information on the 8253 timer itself, I refer you to Intel’s Microsystem Components Handbook, which is also a useful reference for a number of other PC components, including the 8259 Programmable Interrupt Controller and the 8237 DMA Controller. For details about the way the 8253 is used in the PC, as well as a great deal of additional information about the PC’s hardware and BIOS resources, I suggest you consult IBM’s series of technical reference manuals for the PC, XT, AT, Model 30, and microchannel computers, such as the Models 50, 60, and 80.
For our purposes, however, it’s not critical that you understand exactly how the Zen timer works. All you really need to know is what the Zen timer can do and how to use it, and we’ve accomplished that in this chapter.
-Armed with the Zen Timer, Onward and Upward
+Armed with the Zen Timer, Onward and Upward
The Zen timer is not perfect. For one thing, the finest resolution to which it can measure an interval is at best about 1µs, a period of time in which a 66 MHz Pentium computer can execute as many as 132 instructions (although an 8088-based PC would be hard-pressed to manage two instructions in a microsecond). Another problem is that the timing code itself interferes with the state of the prefetch queue and processor cache at the start of the code being timed, because the timing code is not necessarily fetched and does not necessarily access memory in exactly the same time sequence as the code immediately preceding the code under measurement normally does. This prefetch effect can introduce as much as 3 to 4 µ of inaccuracy. Similarly, the state of the prefetch queue at the end of the code being timed affects how long the code that stops the timer takes to execute. Consequently, the Zen timer tends to be more accurate for longer code sequences, since the relative magnitude of the inaccuracy introduced by the Zen timer becomes less over longer periods.
Imperfections notwithstanding, the Zen timer is a good tool for exploring C code and x86 family assembly language, and it’s a tool we’ll use frequently for the remainder of this book.
--
diff --git a/04-01.html b/04-01.html index 23a9aa2..c5cf83d 100644 --- a/04-01.html +++ b/04-01.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
Chapter 4
@@ -57,7 +60,7 @@
In the Lair of the Cycle-EatersThe nature and severity of the cycle-eaters vary enormously from processor to processor, and (especially) from memory architecture to memory architecture. In order to understand them all, we need first to understand the simplest among them, those that haunted the original 8088-based IBM PC. Later on in this book, I’ll be better able to explain the newer generation of cycle-eaters in terms of those ancestral cycle-eaters—but we have to get the groundwork down first.
-The 8088’s Ancestral Cycle-Eaters
+The 8088’s Ancestral Cycle-Eaters
Internally, the 8088 is a 16-bit processor, capable of running at full speed at all times—unless external data is required. External data must traverse the 8088’s external data bus and the PC’s data bus one byte at a time to and from peripherals, with cycle-eaters lurking along every step of the way. What’s more, external data includes not only memory operands but also instruction bytes, so even instructions with no memory operands can suffer from cycle-eaters. Since some of the 8088’s fastest instructions are register-only instructions, that’s important indeed.
@@ -85,16 +88,20 @@The 8088 is internally a full 16-bit processor, equivalent to an 8086. (In fact, the 8086 is identical to the 8088, except that it has a full 16-bit bus. The 8088 is basically the poor man’s 8086, because it allows a cheaper—albeit slower—system to be built, thanks to the half-sized bus.) In terms of the instruction set, the 8088 is clearly a 16-bit processor, capable of performing any given 16-bit operation—addition, subtraction, even multiplication or division—with a single instruction. Externally, however, the 8088 is unequivocally an 8-bit processor, since the external data bus is only 8 bits wide. In other words, the programming interface is 16 bits wide, but the hardware interface is only 8 bits wide, as shown in Figure 4.2. The result of this mismatch is simple: Word-sized data can be transferred between the 8088 and memory or peripherals at only one-half the maximum rate of the 8086, which is to say one-half the maximum rate for which the Execution Unit of the 8088 was designed.
--
diff --git a/04-02.html b/04-02.html index 3bc1f86..ad6024c 100644 --- a/04-02.html +++ b/04-02.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
@@ -42,7 +45,7 @@
Figure 4.1 The location of the major cycle-eaters in the IBM PC.A related cycle-eater lurks beneath the 386SX chip, which is a 32-bit processor internally with only a 16-bit path to system memory. The numbers are different, but the way the cycle-eater operates is exactly the same. AT-compatible systems have 16-bit data buses, which can access a full 16-bit word at a time. The 386SX can process 32 bits (a doubleword) at a time, however, and loses a lot of time fetching that doubleword from memory in two halves.
-The Impact of the 8-Bit Bus Cycle-Eater
+The Impact of the 8-Bit Bus Cycle-Eater
One obvious effect of the 8-bit bus cycle-eater is that word-sized accesses to memory operands on the 8088 take 4 cycles longer than byte-sized accesses. That’s why the official instruction timings indicate that for code running on an 8088 an additional 4 cycles are required for every word-sized access to a memory operand. For instance,
@@ -70,7 +73,7 @@ add byte ptr [MemVar],alThe upshot of all this is simply that the 8088 can transfer word-sized data to and from memory at only half the speed of the 8086, which inevitably causes performance problems when coupled with an Execution Unit that can process word-sized data every bit as quickly as an 8086. These problems show up with any code that uses word-sized memory operands. More ominously, as we will see shortly, the 8-bit bus cycle-eater can cause performance problems with other sorts of code as well.
-What to Do about the 8-Bit Bus Cycle-Eater?
+What to Do about the 8-Bit Bus Cycle-Eater?
The obvious implication of the 8-bit bus cycle-eater is that byte-sized memory variables should be used whenever possible. After all, the 8088 performs byte-sized memory accesses just as quickly as the 8086. For instance, Listing 4.1, which uses a byte-sized memory variable as a loop counter, runs in 10.03 s per loop. That’s 20 percent faster than the 12.05 µs per loop execution time of Listing 4.2, which uses a word-sized counter. Why the difference in execution times? Simply because each word-sized DEC performs 4 byte-sized memory accesses (two to read the word-sized operand and two to write the result back to memory), while each byte-sized DEC performs only 2 byte-sized memory accesses in all.
@@ -110,16 +113,20 @@ LoopTop:I’d like to make a brief aside concerning code optimization in the listings in this book. Throughout this book I’ve modeled the sample code after working code so that the timing results are applicable to real-world programming. In Listings 4.1 and 4.2, for example, I could have shown a still greater advantage for byte-sized operands simply by performing 1,000 DEC instructions in a row, with no branching at all. However, DEC instructions don’t exist in a vacuum, so in the listings I used code that both decremented the counter and tested the result. The difference is that between decrementing a memory location (simply an instruction) and using a loop counter (a functional instruction sequence). If you come across code in this book that seems less than optimal, it’s simply due to my desire to provide code that’s relevant to real programming problems. On the other hand, optimal code is an elusive thing indeed; by no means should you assume that the code in this book is ideal! Examine it, question it, and improve upon it, for an inquisitive, skeptical mind is an important part of the Zen of assembly optimization.
--
diff --git a/04-03.html b/04-03.html index c79e9b6..067e6d6 100644 --- a/04-03.html +++ b/04-03.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
Back to the 8-bit bus cycle-eater. As I’ve said, in 8088 work you should strive to use byte-sized memory variables whenever possible. That does not mean that you should use 2 byte-sized memory accesses to manipulate a word-sized memory variable in preference to 1 word-sized memory access, as, for instance,
mov dl,byte ptr [MemVar] @@ -105,16 +108,20 @@ shr ax,1should execute in 10 cycles, since each SHR takes 2 cycles to execute, according to Intel’s specifications. Those specifications contain Intel’s official instruction execution times, but in this case—and in many others—the specifications are drastically wrong. Why? Because they describe execution time once an instruction reaches the prefetch queue. They say nothing about whether a given instruction will be in the prefetch queue when it’s time for that instruction to run, or how long it will take that instruction to reach the prefetch queue if it’s not there already. Thanks to the low performance of the 8088’s external data bus, that’s a glaring omission—but, alas, an unavoidable one. Let’s look at why the official execution times are wrong, and why that can’t be helped.
--
diff --git a/04-04.html b/04-04.html index 2435cf4..085c237 100644 --- a/04-04.html +++ b/04-04.html @@ -1,5 +1,4 @@ - + @@ -19,18 +18,22 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + - -
Official Execution Times Are Only Part of the Story
+Official Execution Times Are Only Part of the Story
The sequence of 5 SHR instructions in the last example is 10 bytes long. That means that it can never execute in less than 24 cycles even if the 4-byte prefetch queue is full when it starts, since 6 instruction bytes would still remain to be fetched, at 4 cycles per fetch. If the prefetch queue is empty at the start, the sequence could take 40 cycles. In short, thanks to instruction fetching, the code won’t run at its documented speed, and could take up to four times longer than it is supposed to.
@@ -48,7 +51,7 @@So now you know why the official instruction execution times are often wrong, and why Intel can’t provide better specifications. You also know now why it is that you must time your code if you want to know how fast it really is.
-There Is No Such Beast as a True Instruction Execution Time
+There Is No Such Beast as a True Instruction Execution Time
The effect of the code preceding an instruction on the execution time of that instruction makes the Zen timer trickier to use than you might expect, and complicates the interpretation of the results reported by the Zen timer. For one thing, the Zen timer is best used to time code sequences that are more than a few instructions long; below 10µs or so, prefetch queue effects and the limited resolution of the clock driving the timer can cause problems.
@@ -96,16 +99,20 @@The key point is this: We’ve seen one code sequence in which SHR took 8-plus cycles to execute, and another in which it took only 2 cycles. Are we talking about two different forms of SHR here? Of course not—the difference is purely a reflection of the differing states in which the preceding code left the prefetch queue. In Listing 4.5, each SHR after the first few follows a slew of other SHR instructions which have sucked the prefetch queue dry, so overall performance reflects instruction fetch time. By contrast, each SHR in Listing 4.6 follows a MUL instruction which leaves the prefetch queue full, so overall performance reflects Execution Unit execution time.
--
diff --git a/04-05.html b/04-05.html index 9c2b7a4..01b5506 100644 --- a/04-05.html +++ b/04-05.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
Clearly, either instruction fetch time or Execution Unit execution time—or even a mix of the two, if an instruction is partially prefetched—can determine code performance. Some people operate under a rule of thumb by which they assume that the execution time of each instruction is 4 cycles times the number of bytes in the instruction. While that’s often true for register-only code, it frequently doesn’t hold for code that accesses memory. For one thing, the rule should be 4 cycles times the number of memory accesses, not instruction bytes, since all accesses take 4 cycles on the 8088-based PC. For another, memory-accessing instructions often have slower Execution Unit execution times than the 4 cycles per memory access rule would dictate, because the 8088 isn’t very fast at calculating memory addresses. Also, the 4 cycles per instruction byte rule isn’t true for register-only instructions that are already in the prefetch queue when the preceding instruction ends.
The truth is that it never hurts performance to reduce either the cycle count or the byte count of a given bit of code, but there’s no guarantee that one or the other will improve performance either. For example, consider Listing 4.7, which consists of a series of 4-cycle, 2-byte MOV AL,0 instructions, and which executes at the rate of 1.81 µs per instruction. Now consider Listing 4.8, which replaces the 4-cycle MOV AL,0 with the 3-cycle (but still 2-byte) SUB AL,AL, Despite its 1-cycle-per-instruction advantage, Listing 4.8 runs at exactly the same speed as Listing 4.7. The reason: Both instructions are 2 bytes long, and in both cases it is the 8-cycle instruction fetch time, not the 3 or 4-cycle Execution Unit execution time, that limits performance.
@@ -79,7 +82,7 @@What we really want is to know how long useful working code takes to run, not how long a single instruction takes, and the Zen timer gives us the tool we need to gather that information. Granted, it would be easier if we could just add up neatly documented instruction execution times—but that’s not going to happen. Without actually measuring the performance of a given code sequence, you simply don’t know how fast it is. For crying out loud, even the people who designed the 8088 at Intel couldn’t tell you exactly how quickly a given 8088 code sequence executes on the PC just by looking at it! Get used to the idea that execution times are only meaningful in context, learn the rules of thumb in this book, and use the Zen timer to measure your code.
-Approximating Overall Execution Times
+Approximating Overall Execution Times
Don’t think that because overall instruction execution time is determined by both instruction fetch time and Execution Unit execution time, the two times should be added together when estimating performance. For example, practically speaking, each SHR in Listing 4.5 does not take 8 cycles of instruction fetch time plus 2 cycles of Execution Unit execution time to execute. Figure 4.3 shows that while a given SHR is executing, the fetch of the next SHR is starting, and since the two operations are overlapped for 2 cycles, there’s no sense in charging the time to both instructions. You could think of the extra instruction fetch time for SHR in Listing 4.5 as being 6 cycles, which yields an overall execution time of 8 cycles when added to the 2 cycles of Execution Unit execution time.
@@ -87,22 +90,26 @@As a working definition, we’ll consider the execution time of a given instruction in a particular context to start when the first byte of the instruction is sent to the Execution Unit and end when the first byte of the next instruction is sent to the EU.
-What to Do about the Prefetch Queue Cycle-Eater?
+What to Do about the Prefetch Queue Cycle-Eater?
Reducing the impact of the prefetch queue cycle-eater is one of the overriding principles of high-performance assembly code. How can you do this? One effective technique is to minimize access to memory operands, since such accesses compete with instruction fetching for precious memory accesses. You can also greatly reduce instruction fetch time simply by your choice of instructions: Keep your instructions short. Less time is required to fetch instructions that are 1 or 2 bytes long than instructions that are 5 or 6 bytes long. Reduced instruction fetching lowers minimum execution time (minimum execution time is 4 cycles times the number of instruction bytes) and often leads to faster overall execution.
While short instructions minimize overall prefetch time, ironically they actually often suffer more from the prefetch queue bottleneck than do long instructions. Short instructions generally have such fast execution times that they drain the prefetch queue despite their small size. For example, consider the SHR of Listing 4.5, which runs at only 25 percent of its Execution Unit execution time even though it’s only 2 bytes long, thanks to the prefetch queue bottleneck. Short instructions are nonetheless generally faster than long instructions, thanks to the combination of fewer instruction bytes and faster Execution Unit execution times, and should be used as much as possible—just don’t expect them to run at their “official” documented speeds.
--
diff --git a/04-06.html b/04-06.html index c3cacf3..8410871 100644 --- a/04-06.html +++ b/04-06.html @@ -1,5 +1,4 @@ - + @@ -19,22 +18,26 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
More than anything, the above rules mean using the registers as heavily as possible, both because register-only instructions are short and because they don’t perform memory accesses to read or write operands. However, using the registers is a rule of thumb, not a commandment. In some circumstances, it may actually be faster to access memory. (The look-up table technique is one such case.) What’s more, the performance of the prefetch queue (and hence the performance of each instruction) differs from one code sequence to the next, and can even differ during different executions of the same code sequence.
All in all, writing good assembler code is as much an art as a science. As a result, you should follow the rules of thumb described here—and then time your code to see how fast it really is. You should experiment freely, but always remember that actual, measured performance is the bottom line.
-Holding Up the 8088
+Holding Up the 8088
In this chapter I’ve taken you further and further into the depths of the PC, telling you again and again that you must understand the computer at the lowest possible level in order to write good code. At this point, you may well wonder, “Have we gotten low enough?”
@@ -54,7 +57,7 @@All of the PC’s system memory consists of DRAM chips. Each DRAM chip in the PC must be completely refreshed about once every four milliseconds in order to ensure the integrity of the data it stores. Obviously, it’s highly desirable that the memory in the PC retain the correct data indefinitely, so each DRAM chip in the PC must always be refreshed within 4 µs of the last refresh. Since there’s no guarantee that a given program will access each and every DRAM block once every 4 µs, the PC contains special circuitry and programming for providing DRAM refresh.
-How DRAM Refresh Works in the PC
+How DRAM Refresh Works in the PC
On the original 8088-based IBM PC, timer 1 of the 8253 timer chip is programmed at power-up to generate a signal once every 72 cycles, or once every 15.08µs. That signal goes to channel 0 of the 8237 DMA controller, which requests the bus from the 8088 upon receiving the signal. (DMA stands for direct memory access, the ability of a device other than the 8088 to control the bus and access memory directly, without any help from the 8088.) As soon as the 8088 is between memory accesses, it gives control of the bus to the 8237, which in conjunction with special circuitry on the PC’s motherboard then performs a single 4-cycle read access to 1 of 256 possible addresses, advancing to the next address on each successive access. (The read access is only for the purpose of refreshing the DRAM; the data that is read isn’t used.)
@@ -65,16 +68,20 @@-
Figure 4.5 The PC bus dynamic RAM (DRAM) refresh.-
diff --git a/04-07.html b/04-07.html index c310a15..c5b759f 100644 --- a/04-07.html +++ b/04-07.html @@ -1,5 +1,4 @@ - + @@ -19,18 +18,22 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + - -
The Impact of DRAM Refresh
+The Impact of DRAM Refresh
Let’s look at examples from opposite ends of the spectrum in terms of the impact of DRAM refresh on code performance. First, consider the series of MUL instructions in Listing 4.9. Since a 16-bit MUL on the 8088 executes in between 118 and 133 cycles and is only 2 bytes long, there should be plenty of time for the prefetch queue to fill after each instruction, even after DRAM refresh has taken its slice of memory access time. Consequently, the prefetch queue should be able to keep the Execution Unit well-supplied with instruction bytes at all times. Since Listing 4.9 uses no memory operands, the Execution Unit should never have to wait for data from memory, and DRAM refresh should have no impact on performance. (Remember that the Execution Unit can operate normally during DRAM refreshes so long as it doesn’t need to request a memory access from the Bus Interface Unit.)
@@ -72,7 +75,7 @@Which of the two cases we’ve examined reflects reality? While either case can happen, the latter case—significant performance reduction, ranging as high as 8.33 percent—is far more likely to occur. This is especially true for high-performance assembly code, which uses fast instructions that tend to cause non-stop instruction fetching.
-What to Do About the DRAM Refresh Cycle-Eater?
+What to Do About the DRAM Refresh Cycle-Eater?
Hmmm. When we discovered the prefetch queue cycle-eater, we learned to use short instructions. When we discovered the 8-bit bus cycle-eater, we learned to use byte-sized memory operands whenever possible, and to keep word-sized variables in registers. What can we do to work around the DRAM refresh cycle-eater?
@@ -88,16 +91,20 @@Wait states are cycles during which a bus access by the CPU to a device on the PC’s bus is temporarily halted by that device while the device gets ready to complete the read or write. Wait states are well and truly the lowest level of code performance. Everything we have discussed (and will discuss)—even DMA accesses—can be affected by wait states.
--
diff --git a/04-08.html b/04-08.html index 0a1d345..a3ee406 100644 --- a/04-08.html +++ b/04-08.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
Wait states exist because the CPU must to be able to coexist with any adapter, no matter how slow (within reason). The 8088 expects to be able to complete each bus access—a memory or I/O read or write—in 4 cycles, but adapters can’t always respond that quickly for a number of reasons. For example, display adapters must split access to display memory between the CPU and the circuitry that generates the video signal based on the contents of display memory, so they often can’t immediately fulfill a request by the CPU for a display memory read or write. To resolve this conflict, display adapters can tell the CPU to wait during bus accesses by inserting one or more wait states, as shown in Figure 4.6. The CPU simply sits and idles as long as wait states are inserted, then completes the access as soon as the display adapter indicates its readiness by no longer inserting wait states. The same would be true of any adapter that couldn’t keep up with the CPU.
Mind you, this is all transparent to executing code. An instruction that encounters wait states runs exactly as if there were no wait states, only slower. Wait states are nothing more or less than wasted time as far as the CPU and your program are concerned.
@@ -69,16 +72,20 @@Enough said. All the memory in the PC is not display memory, however, and unless you’re thickheaded enough to put code in display memory, the PC isn’t going to run as slowly as a PCjr. (Putting code or other non-video data in unused areas of display memory sounds like a neat idea—until you consider the effect on instruction prefetching of cutting the 8088’s already-poor memory access performance in half. Running your code from display memory is sort of like running on a hypothetical 8084—an 8086 with a 4-bit bus. Not recommended!) Given that your code and data reside in normal system memory below the 640K mark, how great an impact does the display adapter cycle-eater have on performance?
--
diff --git a/04-09.html b/04-09.html index 2ea20bc..bffae2b 100644 --- a/04-09.html +++ b/04-09.html @@ -1,5 +1,4 @@ - + @@ -19,20 +18,24 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
The answer varies considerably depending on what display adapter and what display mode we’re talking about. The display adapter cycle-eater is worst with the Enhanced Graphics Adapter (EGA) and the original Video Graphics Array (VGA). (Many VGAs, especially newer ones, insert many fewer wait states than IBM’s original VGA. On the other hand, Super VGAs have more bytes of display memory to be accessed in high-resolution mode.) While the Color/Graphics Adapter (CGA), Monochrome Display Adapter (MDA), and Hercules Graphics Card (HGC) all suffer from the display adapter cycle-eater as well, they suffer to a lesser degree. Since the VGA represents the base standard for PC graphics now and for the foreseeable future, and since it is the hardest graphics adapter to wring performance from, we’ll restrict our discussion to the VGA (and its close relative, the EGA) for the remainder of this chapter.
-The Impact of the Display Adapter Cycle-Eater
+The Impact of the Display Adapter Cycle-Eater
Even on the EGA and VGA, the effect of the display adapter cycle-eater depends on the display mode selected. In text mode, the display adapter cycle-eater is rarely a major factor. It’s not that the cycle-eater isn’t present; however, a mere 4,000 bytes control the entire text mode display, and even with the display adapter cycle-eater it just doesn’t take that long to manipulate 4,000 bytes. Even if the display adapter cycle-eater were to cause the 8088 to take as much as 5µs per display memory access—more than five times normal—it would still take only 4,000x 2x 5µs, or 40 µs, to read and write every byte of display memory. That’s a lot of time as measured in 8088 cycles, but it’s less than the blink of an eye in human time, and video performance only matters in human time. After all, the whole point of drawing graphics is to convey visual information, and if that information can be presented faster than the eye can see, that is by definition fast enough.
@@ -102,16 +105,20 @@Bear in mind that we’re talking about a worst case here; the impact of the display adapter cycle-eater is proportional to the percent of time a given code sequence spends accessing display memory.
--
diff --git a/04-10.html b/04-10.html index 9106ff7..1e8ec5c 100644 --- a/04-10.html +++ b/04-10.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
|
@@ -42,7 +45,7 @@
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Chapter 5
Crossing the Border
@@ -59,7 +62,7 @@
And with that, let’s look at a fairly complex application of restartable blocks.
-Searching for Text
+Searching for Text
The application we’re going to examine searches a file for a specified string. We’ll develop a program that will search the file specified on the command line for a string (also specified on the comline), then report whether the string was found or not. (Because the searched-for string is obtained via argv, it can’t contain any whitespace characters.)
@@ -75,16 +78,20 @@The easiest approach would be to use a C/C++ library function. The closest match to what we need is strstr(), which searches one string for the first occurrence of a second string. However, while strstr() would work, it isn’t ideal for our purposes. The problem is this: Where we want to search a fixed-length buffer for the first occurrence of a string, strstr() searches a string for the first occurrence of another string.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
We could put a zero byte at the end of our buffer to allow strstr() to work, but why bother? The strstr() function must spend time either checking for the end of the string being searched or determining the length of that string—wasted effort given that we already know exactly how long our search buffer is. Even if a given strstr() implementation is well-written, its performance will suffer, at least for our application, from unnecessary overhead.
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
LISTING 5.1 SEARCH.C
/* Program to search the file specified by the first command-line
@@ -199,16 +202,20 @@ main(int argc, char *argv[]) {
}
- | Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Interpreting Where the Cycles Go
To boost the overall performance of Listing 5.1, I would normally convert SearchForString() to assembly language at this point. However, I’m not going to do that, and the reason is as important a lesson as any discussion of optimized assembly code is likely to be. Take a moment to examine some interesting performance aspects of the C implementation, and all should become much clearer.
@@ -46,7 +49,7 @@Not likely.
-Knowing When Assembly Is Pointless
+Knowing When Assembly Is Pointless
So that’s why we’re not going to go to assembly language in this example—which is not to say it would never be worth converting the search engine in Listing 5.1 to assembly.
@@ -54,16 +57,20 @@In contrast, Listing 5.1 must return from memchr(), set up parameters, and call memcmp() in order to do the same thing. Likewise, assembly can switch back to REPNZ SCASB after a non-match much more quickly than Listing 5.1. The switching overhead is high; when searching a file completely filled with the character z for the string “zy,” Listing 5.1 takes almost 1/2 minute, or nearly an order of magnitude longer than when searching a file filled with normal text.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
It might also be worth converting the search engine to assembly for searches performed entirely in memory; with the overhead of file access eliminated, improvements in search-engine performance would translate directly into significantly faster overall performance. One such application that would have much the same structure as Listing 5.1 would be searching through expanded memory buffers, and another would be searching through huge (segment-spanning) buffers.
And so we find, as we so often will, that optimization is definitely not a cut-and-dried matter, and that there is no such thing as a single “best” approach.
@@ -66,16 +69,20 @@Would you?
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Chapter 6
Looking Past Face Value
@@ -59,7 +62,7 @@
In short, the x86 family can do much more than you think—if you’ll use everything it has to offer. Give it a shot!
-Memory Addressing and Arithmetic
+Memory Addressing and Arithmetic
Years ago, I saw a clip on the David Letterman show in which Letterman walked into a store by the name of “Just Lamps” and asked, “So what do you sell here?”
@@ -86,16 +89,20 @@ mov al,[bx] mov al,[bx+si] -| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
The two approaches are functionally interchangeable but not equivalent from a performance standpoint, and which is better depends on the particular context. If it’s a one-shot memory access, it’s best to let the processor perform the addition; it’s generally faster at doing this than a separate ADD instruction would be. If it’s a memory access within a loop, however, it’s advantageous on the 8088 CPU to perform the addition outside the loop, if possible, reducing effective address calculation time inside the loop, as in the following:
add bx,si
@@ -83,7 +86,7 @@ lea di,[si+2]
Figure 6.1 Operation of ADD Reg,Reg vs. LEA Reg,{Addr}.
- The Wonders of LEA on the 386
+ The Wonders of LEA on the 386
LEA really comes into its own as a “super-ADD” instruction on the 386, 486, and Pentium, where it can take advantage of the enhanced memory addressing modes of those processors. (The 486 and Pentium offer the same modes as the 386, so I’ll refer only to the 386 from now on.) The 386 can do two very interesting things: It can use any 32-bit register (EAX, EBX, and so on) as the memory addressing base register and/or the memory addressing index register, and it can multiply any 32-bit register used as an index by two, four, or eight in the process of calculating a memory address, as shown in Figure 6.2. Let’s see what that’s good for.
@@ -137,16 +140,20 @@ add ebx,edx
I’d like to extend my thanks to Duane Strong of Metagraphics for his help in brainstorming uses for the 386 version of LEA and for pointing out the complications of 486 instruction timings.
-
-
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
diff --git a/07-01.html b/07-01.html
index 6a41bd7..cea1868 100644
--- a/07-01.html
+++ b/07-01.html
@@ -1,5 +1,4 @@
-
+
@@ -19,17 +18,21 @@
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
-
Chapter 7
Local Optimization
@@ -67,7 +70,7 @@
And yes, in case you’re wondering, the above story is indeed true. Was I there? Let me put it this way: If I were, I’d never admit it!
- When LOOP Is a Bad Idea
+ When LOOP Is a Bad Idea
Let’s examine first an instruction that is less than it appears to be: LOOP. There’s no mystery about what LOOP does; it decrements CX and branches if CX doesn’t decrement to zero. It’s so beautifully suited to the task of counting down loops that any experienced x86 programmer instinctively stuffs the loop count in CX and reaches for LOOP when setting up a loop. That’s fine—LOOP does, of course, work as advertised—but there is one problem:
@@ -89,16 +92,20 @@
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
By the way, don’t fall victim to the lures of JCXZ and do something like this:
and cx,ofh ;Isolate the desired field @@ -50,7 +53,7 @@ jz SkipLoop ;If field is 0, don’t botherIn particular, if you’re going to write 386 protected mode code, which will run only on the 386, 486, and Pentium, you’d be well advised to rethink your use of the more esoteric members of the x86 instruction set. LOOP, JCXZ, the various accumulator-specific instructions, and even the string instructions in many circumstances no longer offer the advantages they did on the 8088. Sometimes they’re just not any faster than more general instructions, so they’re not worth going out of your way to use; sometimes, as with LOOP, they’re actually slower, and you’d do well to avoid them altogether in the 386/486 world. Reviewing the instruction cycle times in the MASM or TASM manuals, or looking over the cycle times in Intel’s literature, is a good place to start; published cycle times are closer to actual execution times on the 386 and 486 than on the 8088, and are reasonably reliable indicators of the relative performance levels of x86 instructions.
-Avoiding LOOPS of Any Stripe
+Avoiding LOOPS of Any Stripe
Cycle counting and directly substituting instructions (DEC CX/JNZ for LOOP, for example) are techniques that belong at the lowest level of optimization. It’s an important level, but it’s fairly mechanical; once you’ve learned the capabilities and relative performance levels of the various instructions, you should be able to select the best instructions fairly easily. What’s more, this is a task at which compilers excel. What I’m saying is that you shouldn’t get too caught up in counting cycles because that’s a small (albeit important) part of the optimization picture, and not the area in which your greatest advantage lies.
@@ -74,16 +77,20 @@ jz SkipLoop ;If field is 0, don’t botherWhen the LOOP in Listing 7.1 is replaced with DEC CX/JNZ, performance improves to 168 µs, less than 2 percent faster than Listing 7.1. Actually, instruction fetching, instruction alignment, cache characteristics, or something similar is affecting these results; I’d expect a slightly larger improvement—around 7 percent—but that’s the most that counting cycles could buy us in this case. (All right, already; LOOPNZ could be used at the bottom of the loop, and other optimizations are surely possible, but all that won’t add up to anywhere near the benefits we’re about to see from local optimization, and that’s the whole point.)
--
diff --git a/07-03.html b/07-03.html index 455846e..e57cfd1 100644 --- a/07-03.html +++ b/07-03.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
LISTING 7.1 L7-1.ASM
; Program to illustrate searching through a buffer of a specified @@ -128,16 +131,20 @@ SearchMaxLengthendpListing 7.2 takes a different tack, unrolling the loop so that four bytes are checked for each LOOP performed. The same instructions are used inside the loop in each listing, but Listing 7.2 is arranged so that three-quarters of the LOOPs are eliminated. Listings 7.1 and 7.2 perform exactly the same task, and they use the same instructions in the loop—the searching algorithm hasn’t changed in any way—but we have sequenced the instructions differently in Listing 7.2, and that makes all the difference.
--
diff --git a/07-04.html b/07-04.html index 0730f35..162d8f4 100644 --- a/07-04.html +++ b/07-04.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
LISTING 7.2 L7-2.ASM
; Program to illustrate searching through a buffer of a specified @@ -172,16 +175,20 @@ SearchMaxLengthendp
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Rotating and Shifting with Tables
+Rotating and Shifting with Tables
As another example of local optimization, consider the matter of rotating or shifting a mask into position. First, let’s look at the simple task of setting bit N of AX to 1.
@@ -80,7 +83,7 @@ BIT_PATTERN=BIT_PATTERN SHL 1NOT Flips Bits—Not Flags
+NOT Flips Bits—Not Flags
The NOT instruction flips all the bits in the operand, from 0 to 1 or from 1 to 0. That’s as simple as could be, but NOT nonetheless has a minor but interesting talent: It doesn’t affect the flags. That can be irritating; I once spent a good hour tracking down a bug caused by my unconscious assumption that NOT does set the flags. After all, every other arithmetic and logical instruction sets the flags; why not NOT? Probably because NOT isn’t considered to be an arithmetic or logical instruction at all; rather, it’s a data manipulation instruction, like MOV and the various rotates. (These are RCR, RCL, ROR, and ROL, which affect only the Carry and Overflow flags.) NOT is often used for tasks, such as flipping masks, where there’s no reason to test the state of the result, and in that context it can be handy to keep the flags unmodified for later testing.
@@ -94,7 +97,7 @@ BIT_PATTERN=BIT_PATTERN SHL 1The x86 instruction set offers many ways to accomplish almost any task. Understanding the subtle distinctions between the instructions—whether and which flags are set, for example—can be critical when you’re trying to optimize a code sequence and you’re running out of registers, or when you’re trying to minimize branching.
-Incrementing with and without Carry
+Incrementing with and without Carry
Another case in which there are two slightly different ways to perform a task involves adding 1 to an operand. You can do this with INC, as in INC AX, or you can do it with ADD, as in ADD AX,1. What’s the difference? The obvious difference is that INC is usually a byte or two shorter (the exception being ADD AL,1, which at two bytes is the same length as INC AL), and is faster on some processors. Less obvious, but no less important, is that ADD sets the Carry flag while INC leaves the Carry flag untouched.
@@ -158,16 +161,20 @@ ADC DX,0As always, pay attention!
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Chapter 8
Speeding Up C with Assembly Language
@@ -55,7 +58,7 @@
Apropos of which, when was the last time you heard of Terry Jacks?
-Billy, Don’t Be a Compiler
+Billy, Don’t Be a Compiler
The key to optimizing C programs with assembly language is, as always, writing good assembly language code, but with an added twist. Rule 1 when converting C code to assembly is this: Don’t think like a compiler. That’s more easily said than done, especially when the C code you’re converting is readily available as a model and the assembly code that the compiler generates is available as well. Nevertheless, the principle of not thinking like a compiler is essential, and is, in one form or another, the basis for all that I’ll discuss below.
@@ -81,16 +84,20 @@What this means is that when you want to speed up a portion of a C program, you should identify the entire critical portion and move all of that critical portion into an assembly language function. You don’t want to move a part of the inner loop into assembly language and then call it from C every time through the loop; the function call and return overhead would be unacceptable. Carve out the critical code en masse and move it into assembly, and try to avoid calls and returns even in your assembly code. True, in assembly you can pass parameters in registers, but the calls and returns themselves are still slow; if the extra cycles they take don’t affect performance, then the code they’re in probably isn’t critical, and perhaps you’ve chosen to convert too much code to assembly, eh?
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Stack Frames Slow So Much
C compilers work within the stack frame model, whereby variables reside in a block of stack memory and are accessed via offsets from BP. Compilers may store a couple of variables in registers and may briefly keep other variables in registers when they’re used repeatedly, but the stack frame is the underlying architecture. It’s a nice architecture; it’s flexible, convenient, easy to program, and makes for fairly compact code. However, stack frames have a few drawbacks. They must be constructed and destroyed, which takes both time and code. They are so easy to use that they tend to bias the assembly language programmer in favor of accessing memory variables more often than might be necessary. Finally, you cannot use BP as a general-purpose register if you intend to access a stack frame, and having that seventh register available is sometimes useful indeed.
@@ -50,7 +53,7 @@In assembly language you have full control over segments. Use it, and, if necessary, reorganize your code to minimize segment loading.
-Why Speeding Up Is Hard to Do
+Why Speeding Up Is Hard to Do
You might think that the most obvious advantage assembly language has over C is that it allows the use of all forms of instructions and all registers in all ways, whereas C compilers tend to use a subset of registers and instructions in a limited number of ways. Yes and no. It’s true that C compilers typically don’t generate instructions such as XLAT, rotates, or the string instructions. On the other hand, XLAT and rotates are useful in a limited set of circumstances, and string instructions are used in the C library functions. In fact, C library code is likely to be carefully optimized by experts, and may be much better than equivalent code you’d produce yourself.
@@ -113,20 +116,24 @@ jz MatchThat said, let me show some of these precepts in action.
-A C-to-Assembly Case Study
+A C-to-Assembly Case Study
Listing 8.1 is the sample C application I’m going to use to examine optimization in action. Listing 8.1 isn’t really complete—it doesn’t handle the “no-matches” case well, and it assumes that the sum of all matches will fit into an int—but it will do just fine as an optimization example.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
LISTING 8.1 L8-1.C
/* Program to search an array spanning a linked list of variable- @@ -193,16 +196,20 @@ $I265: $FB264:-
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
It’s hard to squeeze much more performance from this code by tweaking it, as exemplified by Listing 8.3, a fine-tuned assembly version of FindIDAverage that was produced by looking at the assembly output of MS C/C++ and tightening it. Listing 8.3 eliminates all stack frame access in the inner loop, but that’s about all the tightening there is to do. The result, as shown in Table 8.1, is that Listing 8.3 runs a modest 11 percent faster than Listing 8.1 on a 386. The results could vary considerably, depending on the nature of the data set searched through (average block size and frequency of matches). But, then, understanding the typical and worst case conditions is part of optimization, isn’t it?
LISTING 8.3 L8-3.ASM
@@ -290,16 +293,20 @@ _FindIDAverage ENDP end -| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Listings 8.5 and 8.6 together go the final step and change the rules in favor of assembly language. Listing 8.5 creates the same list of linked blocks as Listing 8.1. However, instead of storing an array of structures within each block, it stores two arrays in each block, one consisting of ID numbers and the other consisting of the corresponding values, as shown in Figure 8.3. No information is lost; the data is merely rearranged.
LISTING 8.5 L8-5.C
@@ -186,16 +189,20 @@ _FindIDAverage2 ENDPI trust you get the picture. The sort of instruction-by-instruction optimization that so many of us love to do as a kind of puzzle is fun, but compilers can do it nearly as well as you can, and in the future will surely do it better. What a compiler can’t do is tie together the needs of the program specification on the high end and the processor on the low end, resulting in critical code that runs just about as fast as the hardware permits. The only software that can do that is located north of your sternum and slightly aft of your nose. Dust it off and put it to work—and your code will never again be confused with anything by Hamilton, Joe, Frank, eynolds or Bo Donaldson and the Heywoods.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Chapter 9
Hints My Readers Gave Me
@@ -64,7 +67,7 @@ X - 1 = 0
I like to think I know more about performance programming than Barry knew about math. Nonetheless, I always welcome good ideas and comments, and many readers have sent me a slew of those over the years. So in this chapter, I think I’ll return the favor by devoting a chapter to reader feedback.
-Another Look at LEA
+Another Look at LEA
Several people have pointed out that while LEA is great for performing certain additions (see Chapter 6), it isn’t a perfect replacement for ADD. What’s the difference? LEA, an addressing instruction by trade, doesn’t affect the flags, while the arithmetic ADD instruction most certainly does. This is no problem when performing additions that involve only quantities that fit in one machine word (32 bits in 386 protected mode, 16 bits otherwise), but it renders LEA useless for multiword operations, which use the Carry flag to tie together partial results. For example, these instructions
@@ -100,7 +103,7 @@ ADDLOOP:-But there sure are a lot of interesting options, aren’t there?
-The Kennedy Portfolio
+The Kennedy Portfolio
Reader John Kennedy regularly passes along intriguing assembly programming tricks, many of which I’ve never seen mentioned anywhere else. John likes to optimize for size, whereas I lean more toward speed, but many of his optimizations are good for both purposes. Here are a few of my favorites:
@@ -140,16 +143,20 @@ REP MOVSB ;copy any odd byte CopyDone:
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
However, it generally is. Sure, if the length is odd, John’s approach incurs a penalty approximately equal to the REP startup time for MOVSB. However, if the length is even, John’s approach doesn’t branch, saving cycles and not emptying the prefetch queue. If copy lengths are evenly distributed between even and odd, John’s approach is faster in most x86 systems. (Not on the 486, though.)
John also points out that on the 386, multiple LEAs can be combined to perform multiplications that can’t be handled by a single LEA, much as multiple shifts and adds can be used for multiplication, only faster. LEA can be used to multiply in a single instruction on the 386, but only by the values 2, 3, 4, 5, 8, and 9; several LEAs strung together can handle a much wider range of values. For example, video programmers are undoubtedly familiar with the following code to multiply AX times 80 (the width in bytes of the bitmap in most PC display modes):
@@ -66,7 +69,7 @@ SHL AX,2 ;*64 ADD AX,BX ;*80 -Speeding Up Multiplication
+Speeding Up Multiplication
That brings us to multiplication, one of the slowest of x86 operations and one that allows for considerable optimization. One way to speed up multiplication is to use shift and add, LEA, or a lookup table to hard-code a multiplication operation for a fixed multiplier, as shown above. Another is to take advantage of the early-out feature of the 386 (and the 486, but in the interests of brevity I’ll just say “386” from now on) by arranging your operands so that the multiplier (always the rightmost operand following MUL or IMUL) is no larger than the other operand.
@@ -96,7 +99,7 @@ ADD AX,BX ;*80That doesn’t mean that your code should test and swap operands to make sure the smaller one is the multiplier; that rarely pays off. I’m speaking more of the case where you’re scaling an array up by a value that’s always in the range of, say, 2 to 10; because the scale value will always be small and the array elements may have any value, the scale value is the logical choice for the multiplier.
-Optimizing Optimized Searching
+Optimizing Optimized Searching
Rob Williams writes with a wonderful optimization to the REPNZ SCASB-based optimized searching routine I discussed in Chapter 5. As a quick refresher, I described searching a buffer for a text string as follows: Scan for the first byte of the text string with REPNZ SCASB, then use REPZ CMPS to check for a full match whenever REPNZ SCASB finds a match for the first character, as shown in Figure 9.1. The principle is that most buffer characters won’t match the first character of any given string, so REPNZ SCASB, by far the fastest way to search on the PC, can be used to eliminate most potential matches; each remaining potential match can then be checked in its entirety with REPZ CMPS.
@@ -115,16 +118,20 @@ ADD AX,BX ;*80Imagine, if you will, that you’re searching for the string “EQUAL.” By my approach, you’d use REPNZ SCASB to scan for each occurrence of “E,” which crops up quite often in normal text. Rob points out that it would make more sense to scan for “Q,” then back up one character and check the whole string when a “Q” is found, as shown in Figure 9.2. “Q” is likely to occur much less often, resulting in many fewer whole-string checks and much faster processing.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Listing 9.1 implements the scan-on-first-character approach. Listing 9.2 scans for whatever character the caller specifies. Listing 9.3 is a test program used to compare the two approaches. How much difference does Rob’s revelation make? Plenty. Even when the entire C function call to FindString is timed—strlen calls, parameter pushing, calling, setup, and all—the version of FindString in Listing 9.2, which is directed by Listing 9.3 to scan for the infrequently-occurring “Q,” is about 40 percent faster on a 20 MHz cached 386 for the test search of Listing 9.3 than is the version of FindString in Listing 9.1, which always scans for the first character, in this case “E.” However, when only the search loops (the code that actually does the searching) in the two versions of FindString are compared, Listing 9.2 is more than twice as fast as Listing 9.1—a remarkable improvement over code that already uses REPNZ SCASB and REPZ CMPS.
What I like so much about Rob’s approach is that it demonstrates that optimization involves much more than instruction selection and cycle counting. Listings 9.1 and 9.2 use pretty much the same instructions, and even use the same approach of scanning with REPNZ SCASB and using REPZ CMPS to check scanning matches.
@@ -140,16 +143,20 @@ _FindStringendp end -| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
LISTING 9.2 L9-2.ASM
; Searches a text buffer for a text string. Uses REPNZ SCASB to scan
@@ -166,16 +169,20 @@ void main() {
}
- | Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
You’ll notice that in Listing 9.2 I didn’t use a table of character frequencies in English text to determine the character for which to scan, but rather let the caller make that choice. Each buffer of bytes has unique characteristics, and English-letter frequency could well be inappropriate. What if the buffer is filled with French text? Cyrillic? What if it isn’t text that’s being searched? It might be worthwhile for an application to build a dynamic frequency table for each buffer so that the best scan character could be chosen for each search. Or perhaps not, if the search isn’t time-critical or the buffer is small.
The point is that you can improve performance dramatically by understanding the nature of the data with which you work. (This is equally true for high-level language programming, by the way.) Listing 9.2 is very similar to and only slightly more complex than Listing 9.1; the difference lies not in elbow grease or cycle counting but in the organic integrating optimizer technology we all carry around in our heads.
-Short Sorts
+Short Sorts
David Stafford (recently of Borland and Borland Japan) who happens to be one of the best assembly language programmers I’ve ever met, has written a C-callable routine that sorts an array of integers in ascending order. That wouldn’t be particularly noteworthy, except that David’s routine, shown in Listing 9.4, is exactly 25 bytes long. Look at the code; you’ll keep saying to yourself, “But this doesn’t work...oh, yes, I guess it does.” As they say in the Prego spaghetti sauce ads, it’s in there—and what a job of packing. Anyway, David says that a 24-byte sort routine eludes him, and he’d like to know if anyone can come up with one.
@@ -74,7 +77,7 @@ _sort: pop dx ;get return address (entry point) end -Full 32-Bit Division
+Full 32-Bit Division
One of the most annoying limitations of the x86 is that while the dividend operand to the DIV instruction can be 32 bits in size, both the divisor and the result must be 16 bits. That’s particularly annoying in regards to the result because sometimes you just don’t know whether the ratio of the dividend to the divisor is greater than 64K-1 or not—and if you guess wrong, you get that godawful Divide By Zero interrupt. So, what is one to do when the result might not fit in 16 bits, or when the dividend is larger than 32 bits? Fall back to a software division approach? That will work—but oh so slowly.
@@ -87,16 +90,20 @@ _sort: pop dx ;get return address (entry point)As for handling signed division with arbitrarily large dividends, that can be done easily enough by remembering the signs of the dividend and divisor, dividing the absolute value of the dividend by the absolute value of the divisor, and applying the stored signs to set the proper signs for the quotient and remainder. There may be more clever ways to produce the same result, by using IDIV, for example; if you know of one, drop me a line c/o Coriolis Group Books.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
LISTING 9.5 L9-5.ASM
; Divides an arbitrarily long unsigned dividend by a 16-bit unsigned
@@ -120,7 +123,7 @@ main() {
}
- Sweet Spot Revisited
+Sweet Spot Revisited
Way back in Volume 1, Number 1 of PC TECHNIQUES, (April/May 1990) I wrote the very first of that magazine’s HAX (#1), which extolled the virtues of placing your most commonly-used automatic (stack-based) variables within the stack’s “sweet spot,” the area between +127 to -128 bytes away from BP, the stack frame pointer. The reason was that the 8088 can store addressing displacements that fall within that range in a single byte; larger displacements require a full word of storage, increasing code size by a byte per instruction, and thereby slowing down performance due to increased instruction fetching time.
@@ -138,16 +141,20 @@ main() {In assembly, it’s easy to control the organization of your stack frame. In C, however, you’ll have to figure out the allocation scheme your compiler uses to allocate automatic variables, and declare automatics appropriately to produce the desired effect. It can be done: I did it in Turbo C some years back, and trimmed the size of a program (admittedly, a large one) by several K—not bad, when you consider that the “sweet spot” optimization is essentially free, with no code reorganization, change in logic, or heavy thinking involved.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Hard-Core Cycle Counting
+Hard-Core Cycle Counting
Next, we come to an item that cycle counters will love, especially since it involves apparently incorrect documentation on Intel’s part. According to Intel’s documents, all RCR and RCL instructions, which perform rotations through the Carry flag, as shown in Figure 9.4, take 9 cycles on the 386 when working with a register operand. My measurements indicate that the 9-cycle execution time almost holds true for multibit rotate-through-carries, which I’ve timed at 8 cycles apiece; for example, RCR AX,CL takes 8 cycles on my 386, as does RCL DX,2. Contrast that with ROR and ROL, which can rotate the contents of a register any number of bits in just 3 cycles.
@@ -43,7 +46,7 @@No great lesson here, just a caution to be leery of multibit RCR and RCL when performance matters—and to take cycle-time documentation with a grain of salt.
-Hardwired Far Jumps
+Hardwired Far Jumps
Did you ever wonder how to code a far jump to an absolute address in assembly language? Probably not, but if you ever do, you’re going to be glad for this next item, because the obvious solution doesn’t work. You might think all it would take to jump to, say, 1000:5 would be JMP FAR PTR 1000:5, but you’d be wrong. That won’t even assemble. You might then think to construct in memory a far pointer containing 1000:5, as in the following:
@@ -84,7 +87,7 @@ start:-If the obvious doesn’t work (and it usually doesn’t), just try everything you can think of, no matter how ridiculous, until you find something that does—a rule with plenty of history on its side.
-Setting 32-Bit Registers: Time versus Space
+Setting 32-Bit Registers: Time versus Space
To finish up this chapter, consider these two items. First, in 32-bit protected mode,
@@ -111,16 +114,20 @@ move bx,-1-Be warned, though, that I’ve found OR, AND, ADD, and the like to be a cycle slower than MOV when working with immediate operands on the 386 under some circumstances, for reasons that thus far escape me. This just reinforces the first rule of optimization: Measure your code in action, and place not your trust in documented cycle times.
--
diff --git a/10-01.html b/10-01.html index 91b8f25..eedc7a5 100644 --- a/10-01.html +++ b/10-01.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
Chapter 10
@@ -57,7 +60,7 @@
Patient Coding, Faster CodeIn this chapter, I’m going to walk you through a simple but illustrative case history that nicely points up the wisdom of delaying gratification when faced with programming problems, so that your mind has time to chew on the problems from other angles. The alternative solutions you find by doing this may seem obvious, once you’ve come up with them. They may not even differ greatly from your initial solutions. Often, however, they will be much better—and you’ll never even have the chance to decide whether they’re better or not if you take the first thing that comes into your head and run with it.
-The Case for Delayed Gratification
+The Case for Delayed Gratification
Once upon a time, I set out to read Algorithms, by Robert Sedgewick (Addison-Wesley), which turned out to be a wonderful, stimulating, and most useful book, one that I recommend highly. My story, however, involves only what happened in the first 12 pages, for it was in those pages that Sedgewick discussed Euclid’s algorithm.
@@ -71,16 +74,20 @@You see, I fell victim to a common programming pitfall, the “brute-force” syndrome. The basis of this syndrome is that there are many problems that have obvious, brute-force solutions—with one small drawback. The drawback is that if you were to try to apply a brute-force solution by hand—that is, work a single problem out with pencil and paper or a calculator—it would generally require that you have the patience and discipline to work on the problem for approximately seven hundred years, not counting eating and sleeping, in order to get an answer. Finding all the prime numbers less than 1,000,000 is a good example; just divide each number up to 1,000,000 by every lesser number, and see what’s left standing. For most of the history of humankind, people were forced to think of cleverer solutions, such as the Sieve of Eratosthenes (we’d have been in big trouble if the ancient Greeks had had computers), mainly because after about five minutes of brute force-type work, people’s attention gets diverted to other important matters, such as how far a paper airplane will fly from a second-story window.
--
diff --git a/10-02.html b/10-02.html index 7044396..1e04d07 100644 --- a/10-02.html +++ b/10-02.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
Not so nowadays, though. Computers love boring work; they’re very patient and disciplined, and, besides, one human year = seven dog years = two zillion computer years. So when we’re faced with a problem that has an obvious but exceedingly lengthy solution, we’re apt to say, “Ah, let the computer do that, it’s fast,” and go back to making paper airplanes. Unfortunately, brute-force solutions tend to be slow even when performed by modern-day microcomputers, which are capable of several MIPS except when I’m late for an appointment and want to finish a compile and run just one more test before I leave, in which case the crystal in my computer is apparently designed to automatically revert to 1 Hz.)
The solution that I instantly came up with to finding the GCD is about as brute- force as you can get: Divide both the larger integer (iL) and the smaller integer (iS) by every integer equal to or less than the smaller integer, until a number is found that divides both evenly, as shown in Figure 10.1. This works, but it’s a lousy solution, requiring as many as iS*2 divisions; very expensive, especially for large values of iS. For example, finding the GCD of 30,001 and 30,002 would require 60,002 divisions, which alone, disregarding tests and branches, would take about 2 seconds on an 8088, and more than 50 milliseconds even on a 25 MHz 486—a very long time in computer years, and not insignificant in human years either.
@@ -240,7 +243,7 @@ unsigned int gcd(unsigned int int1, unsigned int int2) { }Wasted Breakthroughs
+Wasted Breakthroughs
Sedgewick’s first solution to the GCD problem was pretty much the one I came up with. He then pointed out that the GCD of iL and iS is the same as the GCD of iL-iS and iS. This was obvious (once Sedgewick pointed it out); by the very nature of division, any number that divides iL evenly nL times and iS evenly nS times must divide iL-iS evenly nL-nS times. Given that insight, I immediately designed a new, faster approach, shown in Listing 10.2.
@@ -277,16 +280,20 @@ unsigned int gcd(unsigned int int1, unsigned int int2) { }
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Listing 10.2 repeatedly subtracts iS from iL until iL becomes less than or equal to iS. If iL becomes equal to iS, then that’s the GCD; alternatively, if iL becomes less than iS, iL and iS switch values, and the process is repeated, as shown in Figure 10.2. The number of iterations this approach requires relative to Listing 10.1 depends heavily on the values of iL and iS, so it’s not always faster, but, as Table 10.1 indicates, Listing 10.2 is generally much better code.
At long last, we’re ready to optimize GCD determination in the classic sense. Table 10.1 shows the performance of Listing 10.4 with and without Microsoft C/C++’s maximum optimization, and also shows the performance of Listing 10.5, an assembly language version of Listing 10.4. Sure, the optimized versions are faster than the unoptimized version of Listing 10.4—but the gains are small compared to those realized from the higher-level optimizations in Listings 10.2 through 10.4. LISTING 10.5 L10-5.ASM And think what you could do with all those extra computer years! This chapter provides an interesting look at the evolution of the x86 architecture, to a greater degree than you might expect, for the x86 family came into full maturity with the 386; the 486 and the Pentium are really nothing more than faster 386s, with very little in the way of new functionality. In contrast, the 286 added a number of instructions, respectable performance, and protected mode to the 8088’s capabilities, and the 386 added more instructions and a whole new set of addressing modes, and brought the x86 family into the 32-bit world that represents the future (and, increasingly, the present) of personal computing. This chapter also provides insight into the effects on optimization of the variations in processors and memory architectures that are common in the PC world. So, although the 286 and 386 no longer represent the mainstream of computing, this chapter is a useful mix of history lesson, x86 overview, and details on two workhorse processors that are still in wide use. While the x86 family is a large one, only a few members of the family—which includes the 8088, 8086, 80188, 80186, 286, 386SX, 386DX, numerous permutations of the 486, and now the Pentium—really matter. This leaves us with just two processors: the 286 and the 386. Each was the PC standard in its day. The 286 is no longer used in new systems, but there are millions of 286-based systems still in daily use. The 386 is still being used in new systems, although it’s on the downhill leg of its lifespan, and it is in even wider use than the 286. The future clearly belongs to the 486 and Pentium, but the 286 and 386 are still very much a part of the present-day landscape. Apart from vastly improved performance, the biggest difference between the 8088 and the 286 and 386 (as well as the later Intel CPUs) is that the 286 introduced protected mode, and the 386 greatly expanded the capabilities of protected mode. We’re only going to talk about real-mode operation of the 286 and 386 in this book, however. Protected mode offers a whole new memory management scheme, one that isn’t supported by the 8088. Only code specifically written for protected mode can run in that mode; it’s an alien and hostile environment for MS-DOS programs. In short, taken as a whole, protected mode programming is a different kettle of fish altogether from what I’ve been describing in this book. There’s certainly a knack to optimizing specifically for protected mode under a given operating system...but it’s not what we’ve been learning, and now is not the time to pursue it further. In general, though, the optimization strategies discussed in this book still hold true in protected mode; it’s just issues specific to protected mode or a particular operating system that we won’t discuss. Under the programming interface, the 286 and 386 differ considerably from the 8088. Nonetheless, with one exception and one addition, the cycle-eaters remain much the same on computers built around the 286 and 386. Next, we’ll review each of the familiar cycle-eaters I covered in Chapter 4 as they apply to the 286 and 386, and we’ll look at the new member of the gang, the data alignment cycle-eater. The one cycle-eater that vanishes on the 286 and 386 is the 8-bit bus cycle-eater. The 286 is a 16-bit processor both internally and externally, and the 386 is a 32-bit processor both internally and externally, so the Execution Unit/Bus Interface Unit size mismatch that plagues the 8088 is eliminated. Consequently, there’s no longer any need to use byte-sized memory variables in preference to word-sized variables, at least so long as word-sized variables start at even addresses, as we’ll see shortly. On the other hand, access to byte-sized variables still isn’t any slower than access to word-sized variables, so you can use whichever size suits a given task best. You might think that the elimination of the 8-bit bus cycle-eater would mean that the prefetch queue cycle-eater would also vanish, since on the 8088 the prefetch queue cycle-eater is a side effect of the 8-bit bus. That would seem all the more likely given that both the 286 and the 386 have larger prefetch queues than the 8088 (6 bytes for the 286, 16 bytes for the 386) and can perform memory accesses, including instruction fetches, in far fewer cycles than the 8088. However, the prefetch queue cycle-eater doesn’t vanish on either the 286 or the 386, for several reasons. For one thing, branching instructions still empty the prefetch queue, so instruction fetching still slows things down after most branches; when the prefetch queue is empty, it doesn’t much matter how big it is. (Even apart from emptying the prefetch queue, branches aren’t particularly fast on the 286 or the 386, at a minimum of seven-plus cycles apiece. Avoid branching whenever possible.) What does this mean? It means that, practically speaking, the 286 as used in the AT doesn’t have a 16-bit bus. From a performance perspective, the 286 in an AT has two-thirds of a 16-bit bus (a 10.7-bit bus?), since every bus access on an AT takes 50 percent longer than it should. A 286 running at 10 MHz should be able to access memory at a maximum rate of 1 word every 200 ns; in a 10 MHz AT, however, that rate is reduced to 1 word every 300 ns by the one-wait-state memory. In short, a close relative of our old friend the 8-bit bus cycle-eater—the system memory wait state cycle-eater—haunts us still on all but zero-wait-state 286 and 386 computers, and that means that the prefetch queue cycle-eater is alive and well. (The system memory wait state cycle-eater isn’t really a new cycle-eater, but rather a variant of the general wait state cycle-eater, of which the display adapter cycle-eater is yet another variant.) While the 286 in the AT can fetch instructions much faster than can the 8088 in the PC, it can execute those instructions faster still. The picture is less clear in the 386 world since there are so many different memory architectures, but similar problems can occur in any computer built around a 286 or 386. The prefetch queue cycle-eater is even a factor—albeit a lesser one—on zero-wait-state machines, both because branching empties the queue and because some instructions can outrun even zero—5 cycles longer than the official execution time.) The data alignment cycle-eater has intriguing implications for speeding up 286/386 code. The expenditure of a little care and a few bytes to make sure that word-sized variables and memory blocks are word-aligned can literally double the performance of certain code running on the 286. Even if it doesn’t double performance, word alignment usually helps and never hurts. Lack of word alignment can also interfere with instruction fetching on the 286, although not to the extent that it interferes with access to word-sized memory variables. The 286 prefetches instructions a word at a time; even if a given instruction doesn’t begin at an even address, the 286 simply fetches the first byte of that instruction at the same time that it fetches the last byte of the previous instruction, as shown in Figure 11.2, then separates the bytes internally. That means that in most cases, instructions run just as fast whether they’re word-aligned or not. There is, however, a non-word-alignment penalty on branches to odd addresses. On a branch to an odd address, the 286 is only able to fetch 1 useful byte with the first instruction fetch following the branch, as shown in Figure 11.3. In other words, lack of word alignment of the target instruction for any branch effectively cuts the instruction-fetching power of the 286 in half for the first instruction fetch after that branch. While that may not sound like much, you’d be surprised at what it can do to tight loops; in fact, a brief story is in order. When I was developing the Zen timer, I used my trusty 10 MHz 286-based AT clone to verify the basic functionality of the timer by measuring the performance of simple instruction sequences. I was cruising along with no problems until I timed the following code: The two ways of looking at the display adapter cycle-eater on 286/386 computers are actually the same. As you’ll recall from my earlier discussion of the matter in Chapter 4, display adapters offer only a limited number of accesses to display memory during any given period of time. The 8088 is capable of making use of most but not all of those slots with REP MOVSW, so the number of memory accesses allowed by a display adapter such as a standard VGA is reasonably well-matched to an 8088’s memory access speed. Granted, access to a VGA slows the 8088 down considerably—but, as we’re about to find out, “considerably” is a relative term. What a VGA does to PC performance is nothing compared to what it does to faster computers. Under ideal conditions, a 286 can access memory much, much faster than an 8088. A 10 MHz 286 is capable of accessing a word of system memory every 0.20 ms with REP MOVSW, dwarfing the 1 byte every 1.31 µs that the 8088 in a PC can manage. However, access to display memory is anything but ideal for a 286. For one thing, most display adapters are 8-bit devices, although newer adapters are 16-bit in nature. One consequence of that is that only 1 byte can be read or written per access to display memory; word-sized accesses to 8-bit devices are automatically split into 2 separate byte-sized accesses by the AT’s bus. Another consequence is that accesses are simply slower; the AT’s bus inserts additional wait states on accesses to 8-bit devices since it must assume that such devices were designed for PCs and may not run reliably at AT speeds. However, the 8-bit size of most display adapters is but one of the two factors that reduce the speed with which the 286 can access display memory. Far more cycles are eaten by the inherent memory-access limitations of display adapters—that is, the limited number of display memory accesses that display adapters make available to the 286. Look at it this way: If REP MOVSW on a PC can use more than half of all available accesses to display memory, then how much faster can code running on a 286 or 386 possibly run when accessing display memory? What can we do about this new, more virulent form of the display adapter cycle-eater? The workaround is the same as it was on the PC: Access display memory as little as you possibly can. The 286 and 386 offer a number of new instructions. The 286 has a relatively small number of instructions that the 8088 lacks, while the 386 has those instructions and quite a few more, along with new addressing modes and data sizes. We’ll discuss the 286 and the 386 separately in this regard. A couple of old instructions gain new features on the 286. For one, the 286 version of PUSH is capable of pushing a constant on the stack. For another, the 286 allows all shifts and rotates to be performed for not just 1 bit or the number of bits specified by CL, but for any constant number of bits. The 386 is somewhat more complex than the 286 regarding new features. Once again, we won’t discuss protected mode, which on the 386 comes with the ability to address up to 4 gigabytes per segment and 64 terabytes in all. In real mode (and in virtual-86 mode, which allows the 386 to multitask MS-DOS applications, and which is identical to real mode so far as MS-DOS programs are concerned), programs running on the 386 are still limited to 1 MB of addressable memory and 64K per segment. The 386 also comes with a slew of new real-mode instructions beyond those supported by the 8088 and 286. These instructions can scan data on a bit-by-bit basis, set the Carry flag to the value of a specified bit, sign-extend or zero-extend data as it’s moved, set a register or memory variable to 1 or 0 on the basis of any of the conditions that can be tested with conditional jumps, and more. (Again, beware: Many of these complex 386-specific instructions are slower than equivalent sequences of simple instructions on the 486 and especially on the Pentium.) What’s more, both old and new instructions support 32-bit operations on the 386. For example, it’s relatively simple to copy data in chunks of 4 bytes on a 386, even in real mode, by using the MOVSD (“move string double”) instruction, or to negate a 32-bit value with NEG eax. Finally, it’s possible in real mode to use the 386’s new addressing modes, in which any 32-bit general-purpose register or pair of registers can be used to address memory. What’s more, multiplication of memory-addressing registers by 2, 4, or 8 for look-ups in word, doubleword, or quadword tables can be built right into the memory addressing mode. (The 32-bit addressing modes are discussed further in later chapters.) In protected mode, these new addressing modes allow you to address a full 4 gigabytes per segment, but in real mode you’re still limited to 64K, even with 32-bit registers and the new addressing modes, unless you play some unorthodox tricks with the segment registers.
@@ -141,20 +144,24 @@ unsigned int gcd(unsigned int int1, unsigned int int2) {
}
- Patient Optimization
+ Patient Optimization
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
; Finds and returns the greatest common divisor of two integers.
@@ -139,16 +142,20 @@ _gcd endp
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
Chapter 11
@@ -39,7 +42,7 @@
Pushing the 286 and 386Family Matters
+ Family Matters
Crossing the Gulf to the 286 and the 386
+ Crossing the Gulf to the 286 and the 386
In the Lair of the Cycle-Eaters, Part II
+ In the Lair of the Cycle-Eaters, Part II
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
Code Alignment
+ Code Alignment
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
@@ -115,16 +118,20 @@ FindChar proc near
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
New Instructions and Features: The 286
+ New Instructions and Features: The 286
New Instructions and Features: The 386
+ New Instructions and Features: The 386
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
LISTING 11.5 L11-5.ASM
; @@ -61,7 +64,7 @@ Skip:-The more things change, the more they remain the same....
-POPF and the 286
+POPF and the 286
We’ve one final 286-related item to discuss: the hardware malfunction of POPF under certain circumstances on the 286.
@@ -73,16 +76,20 @@ Skip:All POPF does is pop the word on top of the stack into the FLAGS register, as shown in Figure 11.4. How can we do that without POPF? Of course, the 286’s designers intended us to use POPF for this purpose, and didn’t intentionally provide any alternative approach, so we’ll have to devise an alternative approach of our own. To do that, we’ll have to search for instructions that contain some of the same functionality as POPF, in the hope that one of those instructions can be used in some way to replace POPF.
--
diff --git a/11-08.html b/11-08.html index f22716a..6e4e6c8 100644 --- a/11-08.html +++ b/11-08.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
Well, there’s only one instruction other than POPF that loads the FLAGS register directly from the stack, and that’s IRET, which loads the FLAGS register from the stack as it branches, as shown in Figure 11.5. iret has no known bugs of the sort that plague POPF, so it’s certainly a candidate to replace popf in non-interruptible applications. Unfortunately, IRET loads the FLAGS register with the third word down on the stack, not the word on top of the stack, as is the case with POPF; the far return address that IRET pops into CS:IP lies between the top of the stack and the word popped into the FLAGS register.
Obviously, the segment:offset that IRET expects to find on the stack above the pushed flags isn’t present when the stack is set up for POPF, so we’ll have to adjust the stack a bit before we can substitute IRET for POPF. What we’ll have to do is push the segment:offset of the instruction after our workaround code onto the stack right above the pushed flags. IRET will then branch to that address and pop the flags, ending up at the instruction after the workaround code with the flags popped. That’s just the result that would have occurred had we executed POPF—WITH the bonus that no interrupts can accidentally occur when the Interrupt flag is 0 both before and after the pop.
@@ -103,16 +106,20 @@ EMULATE_POPFmacroAnd now you know the nature of and the workaround for the POPF bug. Whether you ever need the workaround or not, it’s a neatly packaged example of the tremendous flexibility of the x86 instruction set.
--
diff --git a/12-01.html b/12-01.html index 506541a..2297eb3 100644 --- a/12-01.html +++ b/12-01.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
Chapter 12
@@ -45,7 +48,7 @@
Pushing the 486Substitute “processor” for the various digging implements, and you get an idea of just how different the optimization rules for the 486 are from what you’re used to. Okay, it’s not quite that bad—but upon encountering a processor where string instructions are often to be avoided and memory-to-register MOVs are frequently as fast as register-to-register MOVs, Dorothy was heard to exclaim (before she sank out of sight in a swirl of hopelessly mixed metaphors), “I don’t think we’re in Kansas anymore, Toto.”
-Enter the 486
+Enter the 486
No chip that is a direct, fully compatible descendant of the 8088, 286, and 386 could ever be called a RISC chip, but the 486 certainly contains RISC elements, and it’s those elements that are most responsible for making 486 optimization unique. Simple, common instructions are executed in a single cycle by a RISC-like core processor, but other instructions are executed pretty much as they were on the 386, where every instruction takes at least 2 cycles. For example, MOV AL, [TestChar] takes only 1 cycle on the 486, assuming both instruction and data are in the cache—3 cycles faster than the 386—but STOSB takes 5 cycles, 1 cycle slower than on the 386. The floating-point execution unit inside the 486 is also much faster than the 387 math coprocessor, largely because, being in the same silicon as the CPU (the 486 has a math coprocessor built in), it is more tightly coupled. The results are sometimes startling: FMUL (floating point multiply) is usually faster on the 486 than IMUL (integer multiply)!
@@ -65,7 +68,7 @@In other words, for cached code (which time-critical code almost always is), performance is predictable and can be calculated with good precision, and those calculations will apply on any 486. However, “predictable” doesn’t mean “trivial”; the cycle times printed for the various instructions are not the whole story. You must be aware of all the rules, documented and undocumented, that go into calculating actual execution times—and uncovering some of those rules is exactly what this chapter is about.
-The Hazards of Indexed Addressing
+The Hazards of Indexed Addressing
Rule #1: Avoid indexed addressing (that is, try not to use either two registers or scaled addressing to point to memory).
@@ -101,16 +104,20 @@ LoopTop: sub si,bx
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
which calculates the same sum and leaves the registers in the same state as the first example, but avoids indexed addressing.
In protected mode, the definition of indexed addressing is a tad more complex. The use of two registers to address memory, as in MOV EAX, [EDX+EDI], still qualifies for the one-cycle penalty. In addition, the use of 386/486 scaled addressing, as in MOV [ECX*2],EAX, also constitutes indexed addressing, even if only one register is used to point to memory.
@@ -40,7 +43,7 @@In a key loop on the 486, 1 cycle can indeed matter.
-Calculate Memory Pointers Ahead of Time
+Calculate Memory Pointers Ahead of Time
Rule #2: Don’t use a register as a memory pointer during the next two cycles after loading it.
@@ -125,16 +128,20 @@ jnz LoopTopA caution: I’m quite certain that the 2-cycle-ahead addressing pipeline interruption penalty I’ve described exists in the two 486s I’ve tested. However, there’s no guarantee that Intel won’t change this aspect of the 486 in the future, especially given that the documentation indicates otherwise. Perhaps the 2-cycle penalty is the result of a bug in the initial steps of the 486, and will revert to the documented 1-cycle penalty someday; likewise for the undocumented optimizations I’ll describe below. Nonetheless, none of the optimizations I suggest would hurt performance even if the undocumented performance characteristics of the 486 were to vanish, and they certainly will help performance on at least some 486s right now, so I feel they’re well worth using.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
There is, of course, no guarantee that I’m entirely correct about the optimizations discussed in this chapter. Without knowing the internals of the 486, all I can do is time code and make inferences from the results; I invite you to deduce your own rules and cross-check them against mine. Also, most likely there are other optimizations that I’m unaware of. If you have further information on these or any other undocumented optimizations, please write and let me know. And, of course, if anyone from Intel is reading this and wants to give us the gospel truth, please do!
-Stack Addressing and Address Pipelining
+Stack Addressing and Address Pipelining
Rule #2A: Rule #2 sometimes, but not always, applies to the stack pointer when it is implicitly used to point to memory.
@@ -74,7 +77,7 @@ pop axI certainly haven’t tried all possible combinations, but the results so far indicate that the stack pointer incurs the addressing pipeline penalty only if (E)SP is the explicit destination of one instruction and is then used by one of the two following instructions to address memory. So, for instance, SP isn’t the explicit operand of POP AX—AX is—and no cycles are lost if POP AX is followed by POP or RET. Happily, then, we need not worry about the sequence in which we use PUSH and POP. However, adding to, moving to, or subtracting from the stack pointer should ideally be done at least two cycles before PUSH, POP, RET, or any other instruction that uses the stack pointer to address memory.
-Problems with Byte Registers
+Problems with Byte Registers
There are two ways to lose cycles by using byte registers, and neither of them is documented by Intel, so far as I know. Let’s start with the lesser and simpler of the two.
@@ -120,16 +123,20 @@ xlatIn general, penalties for interrupting the 486’s pipeline apply primarily to the fast core instructions of the 486, most notably register-only instructions and MOV, although arithmetic and logical operations that access memory are also often affected. I don’t know all the performance dependencies, and I don’t plan to; figuring all of them out would be a big, boring job of little value. Basically, on the 486 you should concentrate on using those fast core instructions when performance matters, and all the rules I’ll discuss do indeed apply to those instructions.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
You don’t need to understand every corner of the 486 universe unless you’re a diehard ASMhead who does this stuff for fun. Just learn enough to be able to speed up the key portions of your programs, and spend the rest of your time on a fast design and overall implementation.
-More Fun with Byte Registers
+More Fun with Byte Registers
Rule #4: Don’t load any byte register exactly 2 cycles before using any register to address memory.
@@ -78,7 +81,7 @@ mov ax,[bx]Timing Your Own 486 Code
+Timing Your Own 486 Code
In case you want to do some 486 performance analysis of your own, let me show you how I arrived at one of the above conclusions; at the same time, I can warn you of the timing hazards of the cache. Listings 12.1 and 12.2 show the code I ran through the Zen timer in order to establish the effects of loading a byte register before using a register to address memory. Listing 12.1 ran in 120 µs on a 33 MHz 486, or 4 cycles per repetition (120 µs/1000 repetitions = 120 ns per repetition; 120 ns per repetition/30 ns per cycle = 4 cycles per repetition); Listing 12.2 ran in 90 µs, or 3 cycles, establishing that loading a byte register costs a cycle only when it’s performed exactly 2 cycles before addressing memory.
@@ -140,16 +143,20 @@ Done:Sometimes it is hard to believe we’re still in Kansas!
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Chapter 13
Aiming the 486
@@ -43,7 +46,7 @@
For example, consider how Terje Mathisen doubled the speed of his word-counting program on a 486 simply by shuffling a couple of instructions.
-486 Pipeline Optimization
+486 Pipeline Optimization
I’ve mentioned Terje Mathisen in my writings before. Terje is an assembly language programmer extraordinaire, and author of the incredibly fast public-domain word-counting program WC (which comes complete with source code; well worth a look, if you want to see what really fast code looks like). Terje’s a regular participant in the ibm.pc/fast.code topic on Bix. In a thread titled “486 Pipeline Optimization, or TANSTATFC (There Ain’t No Such Thing As The Fastest Code),” he detailed the following optimization to WC, perhaps the best example of 486 pipeline optimization I’ve yet seen.
@@ -82,16 +85,20 @@ add dx,[bx+8000h] ;increment word and line countAt this point, Terje had nearly doubled the performance of this code simply by moving one instruction. (Note that swapping the instructions also made it necessary to preload DI at the start of the loop; Listing 13.2 is not exactly equivalent to Listing 13.1.) I’ll let Terje describe his next optimization in his own words:
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
“When I looked closely as this, I realized that the two cycles for the final ADD is just the sum of 1 cycle to load the data from memory, and 1 cycle to add it to DX, so the code could just as well have been written as shown in Listing 13.3. The final breakthrough came when I realized that by initializing AX to zero outside the loop, I could rearrange it as shown in Listing 13.4 and do the final ADD DX,AX after the loop. This way there are two single-cycle instructions between the first and the fourth line, avoiding all pipeline stalls, for a total throughput of two cycles/char.”
LISTING 13.3 L13-3.ASM
@@ -88,16 +91,20 @@ looptop:Not necessarily. Shifts and rotates are among the worst performing instructions of the 486, taking 2 to 3 cycles to execute. Thus, it takes 2 cycles to rotate the skip value into CX in Listing 13.5, and 2 more cycles to rotate it back to the upper half of ECX. I’d say four cycles is a pretty steep price to pay, especially considering that a MOV to or from memory takes only one cycle. Basically, using ROR to access a 16-bit value in the upper half of a 16-bit register is a pretty marginal technique, unless for some reason you can’t access memory at all (for example, if you’re using BP as a working register, temporarily making the stack frame inaccessible).
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
On the 386, ROR was the only way to split a 32-bit register into two 16-bit registers. On the 486, however, BSWAP can not only do the job, but can do it better, because BSWAP executes in just one cycle. BSWAP has the added benefit of not affecting any flags, unlike ROR. With BSWAP-based code like that in Listing 13.6, the upper 16 bits of a register can be accessed with only 2 cycles of overhead and without altering any flags, making the technique of packing two 16-bit registers into one 32-bit register much more useful.
LISTING 13.6 L13-6.ASM
@@ -89,16 +92,20 @@ mov dx,axAgain, this technique is advantageous only on a 486. It also doesn’t apply to RCL and RCR, where you definitely want to use the 1-bit versions whenever you can, because the n-bit versions are horrendously slow. But if you’re optimizing for the 486, these tidbits can save a few critical cycles—and Lord knows that if you’re optimizing for the 486—that is, if you need even more performance than you get from unoptimized code on a 486—you almost certainly need all the speed you can get.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
32-Bit Addressing Modes
The 386 and 486 both support 32-bit addressing modes, in which any register may serve as the base memory addressing register, and almost any register may serve as the potentially scaled index register. For example,
@@ -77,16 +80,20 @@ LoopTop:Lastly, as I mentioned, ESP cannot be scaled. In fact, ESP cannot be an index register; it must be a base register. Ironically, however, ESP is the one register that cannot be used to address memory without the presence of an SIB byte, even if it’s used without an index register. This is an outcome of the way in which the SIB byte extends the capabilities of the Mod-R/M byte, and there’s nothing to be done about it, but it’s at least worth noting that ESP-based, non-indexed addressing makes for instructions that are a byte larger than other non-indexed addressing (but not any slower; there’s no 1-cycle penalty for using ESP as a base register) on the 486.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Chapter 14
Boyer-Moore String Searching
@@ -77,16 +80,20 @@
Actually, yes, we can.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
The Boyer-Moore Algorithm
All our a priori knowledge of string searching is stated above, but there’s another sort of knowledge—knowledge that’s generated dynamically. As we search through the buffer, we acquire information each time we check for a match. One sort of information that we acquire is based on partial matches; we can often skip ahead after partial matches because (take a deep breath!) by partially matching, we have already implicitly done a comparison of the partially matched buffer characters with all possible pattern start locations that overlap those partially-matched bytes.
@@ -71,16 +74,20 @@The best case for Boyer-Moore is good indeed: About N/M comparisons are required, where N is the buffer length and M is the pattern length. This reflects the ability of Boyer-Moore to skip ahead by a full pattern length on a complete mismatch.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
How fast is Boyer-Moore? Listing 14.1 is a C implementation of Boyer-Moore searching; Listing 14.2 is a test-bed program that searches up to the first 32K of a file for a pattern. Table 14.1 (all times measured with Turbo Profiler on a 20 MHz cached 386, searching a modified version of the text of this chapter) shows that this implementation is generally much slower than REPNZ SCASB, although it does come close when searching for long patterns. Listing 14.1 is designed primarily to make later assembly implemenmore comprehensible, rather than faster; Sedge’s implementation uses arrays rather than pointers, is a great deal more compact and very clever, and may be somewhat faster. Regardless, the far superior performance of REPNZ SCASB clearly indicates that assembly language is in order at this point.
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
LISTING 14.1 L14-1.C
/* Searches a buffer for a specified pattern. In case of a mismatch,
@@ -179,16 +182,20 @@ void main() {
Well, architecture carries a lot of weight, but it sure as heck isn’t destiny. I had simply fallen into the trap of figuring that the algorithm was so clever that I didn’t have to do any thinking myself. The path leading to REPNZ SCASB from the original brute-force approach of REPZ CMPSB at every location had been based on my observation that the first character comparison at each buffer location usually fails. Why not apply the same concept to Boyer-Moore? Listing 14.3 is just like the standard implementation—except that it’s optimized to handle a first-comparison mismatch as quickly as possible in the loop at QuickSearchLoop, much as REPNZ SCASB optimizes first-comparison mismatches for the brute-force approach. The results in Table 14.1 speak for themselves; Listing 14.3 is more than twice as fast as what I assure you was already a nice, tight assembly implementation (and unrolling QuickSearchLoop could boost performance by up to 10 percent more). Listing 14.3 is also four times faster than REPNZ SCASB in one case.
-
-
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
diff --git a/14-05.html b/14-05.html
index faf4b1a..f24ece0 100644
--- a/14-05.html
+++ b/14-05.html
@@ -1,5 +1,4 @@
-
+
@@ -19,17 +18,21 @@
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
-
LISTING 14.3 L14-3.ASM
; Searches a buffer for a specified pattern. In case of a mismatch,
@@ -194,16 +197,20 @@ _FindString endp
end
-
-
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
diff --git a/14-06.html b/14-06.html
index 2e6afda..2a0992a 100644
--- a/14-06.html
+++ b/14-06.html
@@ -1,5 +1,4 @@
-
+
@@ -19,17 +18,21 @@
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
-
Table 14.1 represents a limited and decidedly unscientific comparison of searching techniques. Nonetheless, the overall trend is clear: For all but the shortest patterns, well-implemented Boyer-Moore is generally as good as or better than—sometimes much better than—brute-force searching. (For short patterns, you might want to use REPNZ SCASB, thereby getting the best of both worlds.)
Know your data and use your smarts. Don’t stop thinking just because you’re implementing a big-name algorithm; you know more than it does.
@@ -196,16 +199,20 @@ _FindString endp
As Yogi Berra might put it, “You don’t know what you know until you know it.”
-
-
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
diff --git a/15-01.html b/15-01.html
index d1e966c..3223f85 100644
--- a/15-01.html
+++ b/15-01.html
@@ -1,5 +1,4 @@
-
+
@@ -19,17 +18,21 @@
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
-
Chapter 15
Linked Lists and plain Unintended Challenges
@@ -70,16 +73,20 @@
Figure 15.1 The basic concept of a linked list.
-
-
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
diff --git a/15-02.html b/15-02.html
index 5e58906..bb708ec 100644
--- a/15-02.html
+++ b/15-02.html
@@ -1,5 +1,4 @@
-
+
@@ -19,17 +18,21 @@
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
-
LISTING 15.1 L15-1.C
/* Deletes the node in a linked list that follows the indicated node.
@@ -143,16 +146,20 @@ struct LinkNode *FindNodeBeforeValueNotLess(
Figure 15.3 Representing an empty list.
-
-
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
diff --git a/15-03.html b/15-03.html
index ee74fef..3b62064 100644
--- a/15-03.html
+++ b/15-03.html
@@ -1,5 +1,4 @@
-
+
@@ -19,17 +18,21 @@
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
-
LISTING 15.5 L15-5.C
/* Finds the first node in a value-sorted linked list that
@@ -142,16 +145,20 @@ struct LinkNode *InsertNodeSorted(struct LinkNode *HeadOfListNode,
}
-
-
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
diff --git a/15-04.html b/15-04.html
index 4b5c24e..e8b15dd 100644
--- a/15-04.html
+++ b/15-04.html
@@ -1,5 +1,4 @@
-
+
@@ -19,17 +18,21 @@
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
-
LISTING 15.7 L15-7.ASM
; C near-callable assembly function for inserting a new node in a
@@ -221,16 +224,20 @@ around: ja save
Before I end this chapter, let me say that I get a lot of feedback from my readers, and it’s much appreciated. Keep those cards, letters, and email messages coming. And if any of you know Jeannie Schweigert, have her drop me a line and let me know how she’s doing these days....
-
-
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
diff --git a/16-01.html b/16-01.html
index 3ae504e..3cbea74 100644
--- a/16-01.html
+++ b/16-01.html
@@ -1,5 +1,4 @@
-
+
@@ -19,17 +18,21 @@
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
-
Chapter 16
There Ain’t No Such Thing as the Fastest Code
@@ -198,16 +201,20 @@
-
-
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
diff --git a/16-02.html b/16-02.html
index abbba4b..5cda1a4 100644
--- a/16-02.html
+++ b/16-02.html
@@ -1,5 +1,4 @@
-
+
@@ -19,17 +18,21 @@
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
-
Listing 16.2 is Listing 16.1 modified to call a function that scans each block for words, and Listing 16.3 contains an assembly function that counts words. Used together, Listings 16.2 and 16.3 are just about twice as fast as Listing 16.1, a good return for a little assembly language. Listing 16.3 is a pretty straightforward translation from C to assembly; the new code makes good use of registers, but the key code—determining whether each byte is a character or not—is still done with the same multiple-sequential-tests approach used by the code that the C compiler generates.
LISTING 16.2 L16-2.C
@@ -178,20 +181,24 @@
end
- Which Way to Go from Here?
+ Which Way to Go from Here?
We could rearrange the tests in light of the nature of the data being scanned; for example, we could perform the tests more efficiently by taking advantage of the knowledge that if a byte is less than ‘0,’ it’s either an apostrophe or not a character at all. However, that sort of fine-tuning is typically good for speedups of only 10 to 20 percent, and I’ve intentionally refrained from implementing this in Listing 16.3 to avoid pointing you down the wrong path; what we need is a different tack altogether. Ponder this. What we really want to know is nothing more than whether a byte is a character, not what sort of character it is. For each byte value, we want a yes/no status, and nothing else—and that description practically begs for a lookup table. Listing 16.4 uses a lookup table approach to boost performance another 50 percent, to three times the performance of the original C code. On a 20 MHz 386, this represents a change from 4.6 to 1.6 seconds, which could be significant—who likes to wait? On an 8088, the improvement in word-counting a large file could easily be 10 or 20 seconds, which is definitely significant.
-
-
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
diff --git a/16-03.html b/16-03.html
index 4807d1a..4d4a938 100644
--- a/16-03.html
+++ b/16-03.html
@@ -1,5 +1,4 @@
-
+
@@ -19,17 +18,21 @@
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
-
LISTING 16.4 L16-4.ASM
; Assembly subroutine for Listing 16.2. Scans through Buffer, of
@@ -147,16 +150,20 @@
So how did the entrants in this particular challenge stack up? More than one claimed a speed-up over my assembly word-counting code of more than three times. On top of the three-times speedup over the original C code that I had already realized, we’re almost up to an order of magnitude faster. You are, of course, entitled to your own opinion, but I consider an order of magnitude to be significant.
-
-
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
diff --git a/16-04.html b/16-04.html
index 3a12c77..22927b3 100644
--- a/16-04.html
+++ b/16-04.html
@@ -1,5 +1,4 @@
-
+
@@ -19,20 +18,24 @@
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
-
Truth to tell, I didn’t expect a three-times speedup; around two times was what I had in mind. Which just goes to show that any code can be made faster than you’d expect, if you think about it long enough and from many different perspectives. (The most potent word-counting technique seems to be a 64K lookup table that allows handling two bytes simultaneously. This is not the sort of technique one comes up with by brute-force optimization.) Thinking (or, worse yet, boasting) that your code is the fastest possible is rollescating on a tightrope in a hurricane; you’re due for a fall, if you catch my drift. Case in point: Terje Mathisen’s word-counting program.
- Blinding Yourself to a Better Approach
+ Blinding Yourself to a Better Approach
Not so long ago, Terje Mathisen, who I introduced earlier in this book, wrote a very fast word-counting program, and posted it on Bix. When I say it was fast, I mean fast; this code was optimized like nobody’s business. We’re talking top-quality code here.
@@ -57,7 +60,7 @@
(Granted, CMP [mem],reg is 1 cycle slower than CMP reg,[mem] on the 286, and they’re both the same on the 8088; in this case, though, the code was specific to the 386. In case you’re curious, both forms take 2 cycles on the 486; quite a lot faster, eh?)
- Watch Out for Luggable Assumptions!
+ Watch Out for Luggable Assumptions!
The first lesson to be learned here is not to lug assumptions that may no longer be valid from the 8088/286 world into the wonderful new world of 386 native-mode programming. The second lesson is that after you’ve slaved over your code for a while, you’re in no shape to see its flaws, or to be able to get the new perspectives needed to speed it up. I’ll bet Terje looked at that [EBX+EAX] addressing a hundred times while trying to speed up his code, but he didn’t really see what it did; instead, he saw what it was supposed to do. Mental shortcuts like this are what enable us to deal with the complexities of assembly language without overloading after about 20 instructions, but they can be a major problem when looking over familiar code.
@@ -81,16 +84,20 @@
The winner was David Stafford, who at the time was working for Borland International; his entry is shown in Listing 16.5. Dave Methvin, whom some of you may recall as a tech editor of the late, lamented PC Tech Journal, was a close second, and Mick Brown, about whom I know nothing more than that he is obviously an extremely good assembly language programmer, was a close third, as shown in Table 16.2, which precedes Listing 16.5. Those three were out ahead of the pack; the fourth-place entry, good as it was (twice as fast as my original code), was twice as slow as David’s winning entry, so you can see that David, Dave, and Mick attained a rarefied level of optimization indeed.
-
-
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
diff --git a/16-05.html b/16-05.html
index 1a70035..ded73b3 100644
--- a/16-05.html
+++ b/16-05.html
@@ -1,5 +1,4 @@
-
+
@@ -19,17 +18,21 @@
- Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
-
Table 16.2 has two times for each entry listed: the first value is the overall counting time, including time spent in the main program, disk I/O, and everything else; the second value is the time actually spent counting words, the time spent in ScanBuffer . The first value is the time perceived by the user, but the second value best reflects the quality of the optimization in each entry, since the rest of the overall execution time is fixed.
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Levels of Optimization
Three levels of optimization were evident in the word-counting entries I received in response to my challenge. I’d briefly describe them as “fine-tuning,” “new perspective,” and “table-driven state machine.” The latter categories produce faster code, but, by the same token, they are harder to design, harder to implement, and more difficult to understand, so they’re suitable for only the most demanding applications. (Heck, I don’t even guarantee that David Stafford’s entry works perfectly, although, knowing him, it probably does; the more complex and cryptic the code, the greater the chance for obscure bugs.)
@@ -42,7 +45,7 @@Optimization Level 1: Good Code
+Optimization Level 1: Good Code
The first level of optimization involves fine-tuning and clever use of the instruction set. The basic framework is still the same as my code (which in turn is basically the same as that of the original C code), but that framework is implemented more efficiently.
@@ -56,16 +59,20 @@Listing 16.6, contributed by Willem Clements, of Granada, Spain, illustrates a variety of level 1 optimizations: the two-loop approach, the use of a 16- rather than 32-bit counter, and the use of LODSW . Together, these optimizations made Willem’s code nearly twice as fast as mine in Listing 16.4. A few details could stand improvement; for example, AND AX,AX is a shorter way to test for zero than CMP AX,0 , and ALIGN 2 could be used. Nonetheless, this is good code, and it’s also fairly compact and reasonably easy to understand. In short, this is an excellent example of how an hour or so of hand-optimization might accomplish significantly improved performance at a reasonable cost in complexity and time. This level of optimization is adequate for most purposes (and, in truth, is beyond the abilities of most programmers).
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Listing 16.6 OPT2.ASM
; @@ -152,16 +155,20 @@“My next shot was to get rid of all the branches in the loop. To do that, I reached back to my college hardware courses. I noticed that we were really looking at an edge triggered device we want to count each time the I’m a character state goes from one to zero. Remembering that XOR on two single-bit values will always return whether the bits are different or the same, I implemented a transition counter. The counter triggers every time a word begins or ends.”
--
diff --git a/16-08.html b/16-08.html index e793435..8b509d0 100644 --- a/16-08.html +++ b/16-08.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
Listing 16.7 L16-7.ASM
ScanLoop: @@ -52,7 +55,7 @@-John’s approach makes it clear that word-counting is nothing more than a fairly simple state machine. The interesting part, of course, is building the fastest state machine.
-Level 3: Breakthrough
+Level 3: Breakthrough
The boundaries between the levels of optimization are not sharply defined. In a sense, level 3 optimization is just like levels 1 and 2, but more so. At level 3, one takes whatever level 2 perspective seems most promising, and implements it as efficiently as possible on the x86. Even more than at level 2, at level 3 this means breaking out of familiar patterns of thinking.
@@ -113,22 +116,26 @@Enough said, I trust.
-Enough Word Counting Already!
+Enough Word Counting Already!
Before I finish up this chapter, I’d like to mention that Terje Mathisen’s WC word-counting program, which I’ve mentioned previously and which is available, with source, on Bix, is in the ballpark with David’s code for performance. What’s more, Terje’s program handles 8-bit ASCII, counts lines as well as words, and supports user-definable separator sets. It’s wonderful code, well worth a look; it also happens to be a great word-counting utility. By the way, Terje builds his 64K table on the fly, at program initialization; this allows for customized tables, shrinks the size of the EXE, and, according to Terje’s calculations, takes less time than loading the table off disk as part of the EXE.
So, has David written the fastest possible word-counting code? Well, maybe—but I have a letter from Terry Holmes, of San Rafael, California, that calculates the theoretical maximum performance of native 386 word-counting code at 5.5 cycles/byte, which would be significantly faster than David’s code. Terry, alas, didn’t bother to implement his design, but maybe I’ll take a shot at it someday. It’d be fun, for sure—but jeez, I’ve got real work to do!
--
diff --git a/17-01.html b/17-01.html index 2b8b55b..44f1f37 100644 --- a/17-01.html +++ b/17-01.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
Chapter 17
@@ -47,7 +50,7 @@
The Game of LifeFirst, I’ll describe the ground rules of Life, implement a very straightforward version in C++, and then speed that version up by about eight times without using any drastically different approaches or any assembly. This may be a little tame for some of you, but be patient; for after that, we’ll haul out the big guns and move into the 30 to 40 times speed-up range. Then in the next chapter, I’ll show you how several programmers really floored it in taking me up on my second Optimization Challenge, which involved the Game of Life.
-The Rules of the Game
+The Rules of the Game
The Game of Life is ridiculously simple. There is a cellmap, consisting of a rectangular matrix of cells, each of which may initially be either on or off. Each cell has eight neighbors: two horizontally, two vertically, and four diagonally. For each succeeding generation of cells, the game logic determines whether each cell will be on or off according to the following rules:
@@ -61,16 +64,20 @@All in all, Listing 17.1 is a clean, compact, and elegant implementation of the Game of Life. Were it not that the code is as slow as molasses, we could stop right here.
--
diff --git a/17-02.html b/17-02.html index fa518f6..dfd8c2c 100644 --- a/17-02.html +++ b/17-02.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
LISTING 17.1 L17-1.CPP
/* C++ Game of Life implementation for any mode for which mode set @@ -288,16 +291,20 @@ void show_text(int x, int y, char *text) }--
diff --git a/17-03.html b/17-03.html index f9cf8ec..eea6ba3 100644 --- a/17-03.html +++ b/17-03.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
Where Does the Time Go?
How slow is Listing 17.1? Table 17.1 shows that even on a 486, Listing 17.1 does fewer than three 96x96 generations per second. (The times in Table 17.1 are for 1,000 generations of a 96x96 cell map with seed=1, LIMIT_18_HZ=0, WRAP_EDGES=1, and magnifier=2, running on a 33 MHz 486.) Since my target is 18 generations per second with a 200x200 cellmap on a 20 MHz 386, Listing 17.1 is too slow by a rather wide margin—75 times too slow, in fact. You might say we have a little optimizing to do.
@@ -182,16 +185,20 @@Having said that, let me hasten to add that algorithmic improvements can make a big difference even when working at a purely abstract level. For a large unordered data set, a high-level Quicksort will beat the pants off the best-implemented insertion sort you can imagine. Still, you can optimize your algorithm from here ’til doomsday, and if you have a fast algorithm running on top of a highly abstract programming model, you’ll almost certainly end up with a slow program. In Listing 17.1, the abstraction that’s killing us is that of looking at the eight neighbors with eight completely independent operations, requiring eight calls to cell_state() and eight calculations of cell address and cell mask. In fact, given the nature of cell storage, the eight neighbors are in a fixed relationship to one another, and the addresses and masks of all eight can generally be found very easily via hard-wired offsets and shifts once the address and mask of any one is known.
--
diff --git a/17-04.html b/17-04.html index 7e9e487..e22a81b 100644 --- a/17-04.html +++ b/17-04.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
There’s a kicker here, though, and that’s the counting of neighbors for cells at the edge of the cellmap. When cellmap wrapping is enabled (so that the cellmap becomes essentially a toroid, with each edge joined seamlessly to the opposite edge, as opposed to having a border of off-cells), neighbors that reside on the other edge of the cellmap can’t be accessed by the standard fixed offset, as shown in Figure 17.1. So, in general, we could improve performance by hard-wiring our neighbor-counting for the bit-per-cell cellmap format, but it seems we’d need a lot of conditional code to handle wrapping, and that would slow things back down again.
@@ -207,16 +210,20 @@ void cellmap::next_generation(cellmap& next_map) }-
diff --git a/17-05.html b/17-05.html index 128a7a7..b5fac2b 100644 --- a/17-05.html +++ b/17-05.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
In Listing 17.3, note the padded cellmap edges, and the alteration of the member functions to compensate for the padding. Also note that the width now has to be a multiple of eight, to facilitate the process of copying the edges to the opposite padding bytes. We have decreased the generality of our Game of Life implementation in exchange for better performance. That’s a very common trade-off, as common as trading memory for performance. As a rule, the more general a program is, the slower it is. A corollary is that often (not always, but often), the more heavily optimized a program is, the more complex and the more difficult to implement it is. You can often improve performance a good deal by implementing only the level of generality you need, but at the same time decreased generality makes it more difficult to change or port the program at some later date. A Game of Life implementation, such as Listing 17.1, that’s built on set_cell(), clear_cell(), and get_cell() is completely general; you can change the cell storage format simply by changing the constructor and those three functions. Listing 17.3 is harder to change because count_neighbors() would also have to be altered, and it’s more complex than any of the other functions.
So, in Listing 17.3, we’ve gotten under the hood and changed the cellmap format a little, and gotten impressive results. But now count_neighbors() is hard-wired for optimized counting, and it’s still taking up more than half the time. Maybe now it’s time to go to assembly?
@@ -140,16 +143,20 @@ neighbor_count++;
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
We’re still not ready for assembly, though; what we need is a new perspective that lends itself to vastly better performance in C++. The Life program in the next section is three to seven times faster than Listing 17.4—and it’s still in C++.
How is this possible? Here are some hints:
@@ -50,7 +53,7 @@I have two objectives to achieve in the remainder of this chapter. First, I want to show that optimization consists of many levels, from assembly language up to conceptual design, and that assembly language kicks in pretty late in the optimization process. Second, I want to encourage you to saturate your brain with everything you know about any particular optimization problem, then make space for your right brain to solve the problem.
-Re-Examining the Task
+Re-Examining the Task
Earlier in this chapter, we looked at a straightforward Game of Life implementation, then increased performance considerably by making the implementation a little less abstract and a little less general. We made a small change to the cellmap format, adding padding bytes off the edges so that pointer arithmetic would always work, but the major optimizations were moving the critical code into a single loop and using pointers rather than member functions whenever possible. In other words, we took what we already knew and made it more efficient.
@@ -75,22 +78,26 @@
Figure 17.3 New cell format.
Acting on What We Know
+Acting on What We Know
Once we’ve changed the cellmap format to store neighbor counts as well as states, with a byte for each cell, we can get another performance boost by again examining what we know about our data. I said earlier that most cells are off during any given generation. This means that most cells have no neighbors that are on. Since the cell map representation for an off-cell that has no neighbors is a zero byte, we can skip over scads of unchanged cells at a pop simply by scanning for non-zero bytes. This is much faster than explicitly testing cell states and neighbor counts, and lends itself beautifully to assembly language implementation as REPZ SCASB or (with a little cleverness) REPZ SCASW. (Unfortunately, there’s no C library function that can scan memory for the next byte that’s non-zero.)
Listing 17.5 is a Game of Life implementation that uses the neighbor-count cell map format and scans for non-zero bytes. On a 20 MHz 386, Listing 17.5 is about 4.5 times faster at calculating generations (that is, the generation engine is 4.5 times faster; I’m ignoring the time consumed by drawing and text display) than Listing 17.4, which is no slouch. On a 33 MHz 486, Listing 17.5 is about 3.5 times faster than Listing 17.4. This is true even though Listing 17.5 must be compiled using the large model. Imagine that—getting a four times speed-up while switching from the small model to the large model!
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
LISTING 17.5 L17-5.CPP
/* C++ Game of Life implementation for any mode for which mode set @@ -307,16 +310,20 @@ void cellmap::init() }-
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
The large model is actually not necessary for the 96x96 cellmap in Listing 17.5. However, I was actually more interested in seeing a fast 200x200 cellmap, and two 200x200 cellmaps can’t fit in a single segment. (This can easily be worked around in assembly language for cellmaps up to a segment in size; beyond that size, cellmap scanning becomes pretty complex, although it can still be efficiently implemented with some clever programming.)
Anyway, using the large model helps illustrate that it’s the data representation and the data processing approach you choose that matter most. Optimization details like memory models and segments and in-line functions and assembly language are important but secondary. Let your mind roam creatively before you start coding. Otherwise, you may find you’re writing well-tuned slow code, which is by no means the same thing as fast code.
@@ -48,7 +51,7 @@No doubt we could get another two to five times improvement with good assembly code—but that’s dwarfed by a 30-times improvement, so optimization at a conceptual level must come first.
-The Challenge That Ate My Life
+The Challenge That Ate My Life
The most recent optimization challenge I laid my community of readers was to write the fastest possible Game of Life generation engine. By “engine” I meant that I didn’t care about time spent in input or output, only time consumed by the call to next-generation. The time spent updating the cellmap was what I wanted people to concentrate on.
@@ -72,16 +75,20 @@Who won? What did I learn? To find out, read on.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Chapter 18
It’s a plain Wonderful Life
@@ -63,16 +66,20 @@
Onward to the code.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Table-Driven Magic
David Stafford won my first Optimization Challenge by means of a huge look-up table and an incredible state machine driven by that table. The table didn’t cause David’s entry to exceed the line limit because David’s submission included code to generate the table on the fly as part of the build process. David has done himself one better this time with his QLIFE program; not only does his build process generate a 64K table, but it also generates virtually all his code, consisting of 17,000-plus lines of assembly language spanning another 64K. What David has done is write the equivalent of a bitblt compiler for the Game of Life; one might in fact call it a Life compiler. What David’s code generates is still a general-purpose program; it takes arbitrary seed values, and can run for an arbitrary number of generations, so it’s not as if David simply hardwired the instructions to draw each successive screen. However, it’s a general-purpose program that is exquisitely tailored to the task it needs to perform.
@@ -96,16 +99,20 @@-
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
LISTING 18.1 BUILD.BAT
bcc -v -D%1=%2;%2=%3;%3=%4;%4=%5;%5=%6;%6=%7;%7=%8;%8 lcomp.c @@ -535,16 +538,20 @@ void main( void ) }-
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
LISTING 18.3 MAIN.C
// MAIN.C @@ -198,16 +201,20 @@ extern unsigned short far ChangeList1[];--
Figure 18.1 Cell triplet storage.-
diff --git a/18-05.html b/18-05.html index 5357767..6ccd4d9 100644 --- a/18-05.html +++ b/18-05.html @@ -1,5 +1,4 @@ - + @@ -19,17 +18,21 @@
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
- Previous ++ Previous + -Table of Contents ++ Table of Contents + -Next ++ Next + -
“The basic idea is to maintain a ‘change list.’ This is an array of pointers into the cell array. Each change list element points to a word which changes in the next generation. This way we don’t have to waste time scanning every cell since most of them do not change. Two passes are made through the change list. The first pass updates the cell display on the screen, sets the life/death status of each cell for this new generation, and updates the neighbor counts for the adjacent cells. There are some efficiencies gained by using cell triplets rather than individual cells since we usually don’t need to set all eight neighbors. [Again, the neighbor counts for cells in the same word are implied by the states of those cells.] The second pass sets the next-generation states for the cells and their neighbors, and in the process builds the change list for the next generation.
“Processing each word is a little complex but very fast. A 64K block of code exists with routines on each 256-byte boundary. Generally speaking, the entry point corresponds to the high byte of the cell word. This byte contains the life/death values and a bit to indicate if this is an edge condition. During the first pass we take the cell triplet word, AND it with 0XFE00, and jump to that address. During the second pass we take the cell triplet word, AND it with 0xFE00, OR it with 0x0100, and jump to that address. [Therefore, there are 128 possible jump targets on the first pass, and 128 more on the second, all on 256-byte boundaries and all keyed off the high 7 bits of the cell triplet state; because bit 8 of the jump index is 0 on the first pass and 1 on the second, there is no conflict. The lower bit isn’t needed for other purposes because only the edge flag bit and the six life/death state bits matter for jumping into David’s state machine. The other nine bits, the bits used for the neighbor counts, are used only in the next step.]
@@ -48,7 +51,7 @@ FS : Video segment GS : Unused
A Layperson’s Overview of QLIFE
+A Layperson’s Overview of QLIFE
Most likely, you’re scratching your head right now in bemusement. I don’t blame you; I felt the same way myself at first. It’s actually pretty simple, though, once you have the hang of it. Basically, David runs down the change list, visiting every cell that’s due to change in this generation, setting it to the new state, drawing it in the new state, and adjusting the counts of all its neighbors. David has a separate assembly routine for every possible change of state for a cell triplet, and he jumps to the proper routine by taking the cell triplet word, masking off the lower 9 bits, and jumping to the address where the appropriate code to perform that particular change of state resides. He does this for every entry in the change list. When this is completed, the current generation has been drawn and updated.
@@ -65,16 +68,20 @@ jmp dxThere Ain’t No Such Thing As the Fastest Code.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Chapter 19
Pentium: Not the Same Old Song
@@ -61,16 +64,20 @@
My first thought upon hearing of the Pentium’s dual pipes was to wonder how often the prefetch queue stalls for lack of instruction bytes, given that the demand for instruction bytes can be twice that of the 486. The answer is: rarely indeed, and then only because the code is not in the internal cache. The 486 has a single 8K cache that stores both code and data, and prefetching can stall if data fetching doesn’t allow time for prefetching to occur (although this rarely happens in practice).
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
|
@@ -40,7 +43,7 @@
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Faster Addressing and More
I’ll spend the rest of this chapter covering a variety of Pentium optimization tips. For starters, effective address calculations (that is, the addition and scaling required to calculate a memory operand’s address, as for example in MOV EAX,[EBX+ECX*2+4]) never take any extra cycles on the Pentium (other than possibly an AGI cycle), even for the use of base+index addressing (as in MOV [ESI+EDI],EAX) or scaling (*2, *4, or *8, as in INC ARRAY[ESI*4]). On the 486, both of the latter cases cause a 1-cycle penalty. The faster effective address calculations have the side effect of making LEA very attractive as an arithmetic instruction. LEA can add any two registers, one of which can be multiplied by one, two, four, or eight, plus a constant value, and can store the result in any register—all in one cycle, apart from AGIs. Not only that, but as we’ll see in the next chapter, LEA can go through either pipe, whereas SHL can only go through the U-pipe, so LEA is often a superior choice for multiplication by three, four, five, eight, or nine. (ADD is the best choice for multiplication by two.) If you use LEA for arithmetic, do remember that unlike ADD and SHL, it doesn’t modify any flags.
@@ -65,16 +68,20 @@ mov eax,[ebx]As with the 486, don’t use ENTER or LEAVE, which are slower than the equivalent discrete instructions. Also, start using TEST reg,reg instead of AND reg,reg or OR reg,reg to test whether a register is zero. The reason, as we’ll see in Chapter 21, is that TEST, unlike AND and OR, never modifies the target register. Although in this particular case AND and OR don’t modify the target register either, the Pentium has no way of knowing that ahead of time, so if AND or OR goes through the U-pipe, the Pentium may have to shut down the V-pipe for a cycle to avoid potential dependencies on the result of the AND or OR. TEST suffers from no such potential dependencies.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Branch Prediction
One brand-spanking-new feature of the Pentium is branch prediction, whereby the Pentium tries to guess, based on past history, which way (or, for conditional jumps, whether or not), your code will jump at each branch, and prefetches along the likelier path. If the guess is correct, the branch or fall-through takes only 1 cycle—2 cycles less than a branch and the same as a fall-through on the 486; if the guess is wrong, the branch or fall-through takes 4 or 5 cycles (if it executes in the U- or V-pipe, respectively)—1 or 2 cycles more than a branch and 3 or 4 cycles more than a fall-through on the 486.
@@ -60,13 +63,13 @@The Pentium has all the instructions of the 486, plus a few new ones. One much-needed instruction that has finally made it into the instruction set is CPUID, which allows your code to determine what processor it’s running on. CPUID is 15 years late, but at least it’s finally here. Another new instruction is CMPXCHG8B, which does a compare and conditional exchange on a qword. CMPXCHG8B doesn’t seem to me to be a particularly useful instruction, but I’m sure Intel wouldn’t have added it without a reason; if you know of a use for it, please pass it along to me.
-486 versus Pentium Optimization
+486 versus Pentium Optimization
Many Pentium optimizations help, or at least don’t hurt, on the 486. Many, but not all—and many do hurt on the 386. As I discuss various Pentium optimizations, I will attempt to note the effects on the 486 as well, but doing this in complete detail would double the sizes of these discussions and make them hard to follow. In general, I’d recommend reserving Pentium optimization for your most critical code, and even there, it’s a good idea to have at least two code paths, one for the 386 and one for the 486/Pentium. It’s also a good idea to time your code on a 486 before and after Pentium-optimizing it, to make sure you haven’t hurt performance on what will be, after all, by far the most important processor over the next couple of years.
With that in mind, is optimizing for the Pentium even worthwhile today? That depends on your application and its market—but if you want absolutely the best possible performance for your DOS and Windows apps on the fastest hardware, Pentium optimization can make your code scream.
-Going Superscalar
+Going Superscalar
In the next chapter, we’ll look into the single biggest element of Pentium performance, cranking up the Pentium’s second execution pipe. This is the area in which compiler technology is most touted for the Pentium, the two thoughts apparently being that (1) most existing code is in C, so recompiling to use the second pipe better is an automatic win, and (2) it’s so complicated to optimize Pentium code that only a compiler can do it well. The first point is a reasonable one, but it does suffer from one flaw for large programs, in that Pentium-optimized code is larger than 486- or 386-optimized code, for reasons that will become apparent in the next chapter. Larger code means more cache misses and more page faults; and while most of the code in any program is not critical to performance, compilers optimize code indiscriminately.
@@ -74,16 +77,20 @@A compiler that generates better code than a good assembly programmer? That’ll be the day.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Chapter 20
Pentium Rules
@@ -70,16 +73,20 @@
The key to Pentium optimization is to view execution as a stream of instructions going through the U- and V-pipes, and to eliminate, as much as possible, instruction mixes that take the V-pipe out of action. In practice, this is not too difficult. The only hard part is keeping in mind the long list of rules governing instruction pairing. The place to begin is with the set of instructions that can go through the V-pipe.
-| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
V-Pipe-Capable Instructions
Any instruction can go through the U-pipe, and, for practical purposes, the U-pipe is always executing instructions. (The exceptions are when the U-pipe execution unit is waiting for instruction or data bytes after a cache miss, and when a U-pipe instruction finishes before a paired V-pipe instruction, as I’ll discuss below.) Only the instructions shown in Table 20.1 can go through the V-pipe. In addition, the V-pipe can execute a separate instruction only when one of the instructions listed in Table 20.2 is executing in the U-pipe; superscalar execution is not possible while any instruction not listed in Table 20.2 is executing in the U-pipe. So, for example, if you use SHR EDX,CL, which takes 4 cycles to execute, no other instructions can execute during those 4 cycles; if, on the other hand, you use SHR EDX,10, it will take 1 cycle to execute in the U-pipe, and another instruction can potentially execute concurrently in the V-pipe. (As you can see, similar instruction sequences can have vastly different performance characteristics on the Pentium.)
@@ -171,16 +174,20 @@ mov [MemVar],edx| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
Lockstep Execution
You may wonder why anyone would bother breaking ADD [MemVar],EAX into three instructions, given that this instruction can go through either pipe with equal ease. The answer is that while the memory-accessing instructions other than MOV, PUSH, and POP listed in Table 20.1 (that is, INC/DEC [mem], ADD/SUB/XOR/AND/OR/CMP/ADC/SBB reg,[mem], and ADD/SUB/XOR/AND/OR/CMP/ADC/SBB [mem],reg/immed) can be paired, they do not provide the 100 percent overlap that we seek. If you look at Tables 20.1 and 20.2, you will see that instructions taking from 1 to 3 cycles can pair. However, any pair of instructions goes through the two pipes in lockstep. This means, for example, that if ADD [EBX],EDX is going through the U-pipe, and INC EAX is going through the V-pipe, the V-pipe will be idle for 2 of the 3 cycles that the U-pipe takes to execute its instruction, as shown in Figure 20.4. Out of the theoretical 6 cycles of work that can be done during this time, we actually get only 4 cycles of work, or 67 percent utilization. Even though these instructions pair, then, this sequence fails to make maximum use of the Pentium’s horsepower.
@@ -82,16 +85,20 @@ add esi,[SourceSkip] ;U-pipe cycles 1 and 2 add edi,[DestinationSkip] ;V-pipe cycles 1 and 2 -| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
| Previous | ++ Previous + | -Table of Contents | ++ Table of Contents + | -Next | ++ Next + |
However, this beneficial pairing does not extend to non-MOV instructions with explicit memory destination operands, such as ADD [EBX],EAX. The Pentium executes only one such memory instruction at a time; if two memory-destination complex instructions get paired, first the U-pipe instruction is executed, and then the V-pipe instruction, with only one cycle of overlap, as shown in Figure 20.6. I don’t know for sure, but I’d guess that this is to guarantee that the two pipes will never perform out-of-order access to any given memory location. Thus, even though AND [EBX],AL pairs with AND [ECX],DL, the two instructions take 5 cycles in all to execute, and 4 cycles of idle time—2 in the U-pipe and 2 in the V-pipe, out of 10 cycles in all—are incurred in the process.
What we’ve just seen is the read-after-write form of the superscalar hazard known as register contention. I’ll return to the subject of register contention in the next chapter; in the remainder of this chapter I’d like to cover a few short items about superscalar execution. The above examples should make it pretty clear that effective superscalar programming puts a lot of strain on the Pentium’s relatively small register set. There are only seven general-purpose registers (I strongly suggest using EBP in critical loops), and it does not help to have to sacrifice one of those registers for temporary storage on each complex memory operation; in pre-superscalar days, we used to employ those handy CISC memory instructions to do all that stuff without using any extra registers. As on the 486, you should keep a careful eye out for AGIs involving the stack pointer. Implicit modifiers of ESP, such as PUSH and POP, are special-cased so you don’t have to worry about AGIs. However, if you explicitly modify ESP with this instruction where an attempt is made to set both EAX and its AL subregister on the same cycle. Write-after-write contention implies that the two instructions comprising the above substitute for MOVZX should have at least one unrelated instruction between them when SUB EAX,EAX executes in the V-pipe. Intel has special-cased some very useful exceptions to register contention. Happily, write-after-read operations do not cause contention. Such operations, as in It’s actually not hard to figure out which instructions go through which pipes; just back up until you find an instruction that can’t pair or can only go through the U-pipe, and work forward from there, given the knowledge that that instruction executes in the U-pipe. The easiest thing to look for is branches. All branch target instructions execute in the U-pipe, as do all instructions after conditional branches that fall through. Instructions with prefix bytes are generally good U-pipe markers, although they’re expensive instructions that should be avoided whenever possible, and have at least one aberration with regard to pipe usage, as discussed below. Shifts, rotates, ADC, SBB, and all other instructions not listed in Table 20.1 in the last chapter are likewise U-pipe markers. The first thing to do is to time the code in Listing 21.1 to verify our analysis. When I unleashed the Zen timer on Listing 21.1, I found, to my surprise, that the code actually takes only five cycles per checksum word processed, not six. A little more experimentation revealed that adding a size prefix to the two-cycle ADD EAX,[ESI] instruction doesn’t cost anything, certainly not the one full cycle in each pipe that a prefix is supposed to take. More experimentation showed that prefix bytes do cost the documented extra cycle when used with one-cycle instructions such as MOV. At this point, my preliminary conclusion is that prefixes can pair with the first cycle of at least some multiple-cycle instructions. Determining exactly why this happens will take further research on my part, but the most important conclusion is that you must measure your code! The first, obvious thing we can do to Listing 21.1 is change ADC AX,0 to ADC EAX,0, eliminating a prefix byte and saving a full cycle. Now we’re down from five to four cycles. What next? Listing 21.2 shows one interesting alternative that doesn’t really buy us anything. Here, we’ve eliminated all size prefixes by doing byte-sized MOVs and ADDs, but because the size prefix on ADD AX,[ESI], for whatever reason, didn’t cost anything in Listing 21.1, our efforts are to no avail—Listing 21.2 still takes 4 cycles per checksummed word. What’s worth noting about Listing 21.2 is the extent to which the code is broken into simple instructions and reordered so as to avoid size prefixes, register contention, AGIs, and data bank conflicts (the latter because both [ESI] and [ESI+1] are in the same cache data bank, as discussed in the last chapter). Listing 21.3 could be made a bit faster yet with some loop unrolling, but that would make the code quite a bit more complex for relatively little return. Instead, why not make the code more complex and get a big return? Listing 21.4 does exactly that by loading one dword at a time to eliminate both the word prefix of Listing 21.1 and the multiple byte-sized accesses of Listing 21.3. An obvious drawback to this is the considerable complexity needed to ensure that the dword accesses are dword-aligned (remember that unaligned dword accesses cost three cycles each), and to handle buffer lengths that aren’t dword multiples. I’ve handled these problems by requiring that the buffer be dword-aligned and a dword multiple in length, which is of course not always the case in the real world. However, the point of these listings is to illustrate Pentium optimization—dword issues, being non-inner-loop stuff, are solvable details that aren’t germane to the main focus. In any case, the complexity and assumptions are well justified by the performance of this code: three cycles per loop, or 1.5 cycles per checksummed word, more than three times the speed of the original code. Again, note that the actual order in which the instructions are arranged is dictated by the various optimization hazards of the Pentium. LISTING 21.4 L21-4.ASM I don’t claim that Listing 21.5 is the fastest possible way to do a TCP/IP checksum on a Pentium; in fact, it isn’t. Unrolling the loop one more time, together with a trick of Terje’s that uses LEA to advance ESI (neither LEA nor DEC affects the carry flag, allowing Terje to add the carry from the previous loop iteration into the next iteration’s checksum via ADC), produces a version that’s a full 33 percent faster. Nonetheless, Listings 21.1 through 21.5 illustrate many of the techniques and considerations in Pentium optimization. Hand-optimization for the Pentium isn’t simple, and requires careful measurement to check the efficacy of your optimizations, so reserve it for when you really, really need it—but when you need it, you need it bad. I’ve mentioned that Pentium-optimized code does fine on the 486, but not always so well on the 386. On a 486, Listing 21.1 runs at 9 cycles per checksummed word, and Listing 21.5 runs at 2.5 cycles per checksummed word, a healthy 3.6-times speedup. On a 386, Listing 21.1 runs at 22 cycles per word; Listing 21.5 runs at 7 cycles per word, a 3.1-times speedup. As is often the case, Pentium optimization helped the other processors, but not as much as it helped the Pentium, and less on the 386 than on the 486. Well, that was certainly easy enough! We’re not going to find any more totally non-functional instructions in ClearS, however, so let’s get on to some serious optimizing. We’ll look first for cases where we know of better instructions for particular tasks than those that were chosen. For example, there’s no need to load any register, whether segment or general, through BX; we can eliminate two instructions by loading ES and DI directly as shown in Listing 22.2. LISTING 22.2 L22-2.ASM Let’s step back and see what this code really does, though. All it does in the end is load one byte addressed relative to BP into AH and another byte addressed relative to BP into AL. Heck, we can just do that directly! Presto—we’ve saved another 6 bytes, and turned two word-sized memory accesses into byte-sized memory accesses as well. Listing 22.5 shows the new code. LISTING 22.5 L22-5.ASM All in all, the Zenned version of ClearS is a vast improvement over the original. Probably not the best possible implementation—never say never!—but an awfully good one. Listing 23.1 is a sample VGA program that pans around an animated 16-color medium-resolution (640x350) playfield. There’s a lot packed into this code; I’m going to focus on the VGA-specific aspects so we don’t get sidetracked. I’m not going to explain how the ball is animated, for example; we’ll get to animation starting in Chapter 42. What I will do is cover each of the VGA features used in this program—the virtual screen, vertical and horizontal panning, color plane manipulation, multi-plane block copying, and page flipping—at a conceptual level, letting the code itself demonstrate the implementation details. We’ll return to many of these concepts in more depth later in this book. A little background is necessary before we’re ready to examine Listing 23.1. The VGA is built around four functional blocks, named the CRT Controller (CRTC), the Sequence Controller (SC), the Attribute Controller (AC), and the Graphics Controller (GC). The single-chip VGA could have been designed to treat the registers for all the blocks as one large set, addressed at one pair of I/O ports, but in the EGA, each of these blocks was a separate chip, and the legacy of EGA compatibility is why each of these blocks has a separate set of registers and is addressed at different I/O ports in the VGA.
@@ -58,7 +61,7 @@ mov [ebx],dl
Register Starvation
+ Register Starvation
Figure 20.8 Prefix delays.
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
Chapter 21
@@ -74,16 +77,20 @@ mov edx,[ebp-8] ;V-pipe cycle 3 lockstep idle
Unleashing the Pentium’s V-Pipe
Figure 21.2 An AGI can cost as many as 3 cycles.
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
sub esp,100h
@@ -92,7 +95,7 @@ mov al,[Var] ;U-pipe cycle 2
Exceptions to Register Contention
+ Exceptions to Register Contention
@@ -140,16 +143,20 @@ LoopTop:
; pair in the U-pipe
-
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
Pentium Optimization in Action
@@ -72,16 +75,20 @@ ckloop:
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
; Calculates TCP/IP (16-bit carry-wrapping) checksum for buffer
@@ -114,20 +117,24 @@ ckloopdone:
A Quick Note on the 386 and 486
+ A Quick Note on the 386 and 486
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
Chapter 22
@@ -91,16 +94,20 @@ ClearS endp
Zenning and the Flexible Mind
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
ClearS proc near
@@ -121,16 +124,20 @@ ClearS endp
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
ClearS proc near
@@ -113,16 +116,20 @@ ClearS endp
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
Part II
Chapter 23
@@ -63,16 +66,20 @@
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
-
Previous
+
+ Previous
+
- Table of Contents
+
+ Table of Contents
+
- Next
+
+ Next
+
At the Core
