Deduped images
This commit is contained in:
James Gregory
parent
4eef8b2919
commit
9e52de9586
233 changed files with 128 additions and 128 deletions
|
|
@ -78,13 +78,13 @@ ADD AX,BX ;*80
|
|||
<!-- END CODE SNIP //-->
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading5"></A><FONT COLOR="#000077">Speeding Up Multiplication</FONT></H4>
|
||||
<P>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, <B>LEA</B>, 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 <B>MUL</B> or <B>IMUL</B>) is no larger than the other operand.</P>
|
||||
<TABLE WIDTH="100%"><TD WIDTH="5%" VALIGN="TOP" ALIGN="LEFT"><IMG SRC="images/09-01i.jpg"><TD WIDTH="95%" VALIGN="TOP" ALIGN="LEFT"><SMALL><I>Why? Because the 386 processes one multiplier bit per cycle and immediately ends a multiplication when all significant bits of the multiplier have been processed, so fewer cycles are required to multiply a large multiplicand times a small multiplier than a small multiplicand times a large multiplier, by a factor of about 1 cycle for each significant multiplier bit eliminated.</I></SMALL>
|
||||
<TABLE WIDTH="100%"><TD WIDTH="5%" VALIGN="TOP" ALIGN="LEFT"><IMG SRC="images/i.jpg"><TD WIDTH="95%" VALIGN="TOP" ALIGN="LEFT"><SMALL><I>Why? Because the 386 processes one multiplier bit per cycle and immediately ends a multiplication when all significant bits of the multiplier have been processed, so fewer cycles are required to multiply a large multiplicand times a small multiplier than a small multiplicand times a large multiplier, by a factor of about 1 cycle for each significant multiplier bit eliminated.</I></SMALL>
|
||||
</TABLE>
|
||||
<P>(There’s a minimum execution time on this trick; below 3 significant multiplier bits, no additional cycles are saved.) For example, multiplication of 32,767 times 1 is 12 cycles faster than multiplication of 1 times 32,727.
|
||||
</P>
|
||||
<P>Choosing the right operand as the multiplier can work wonders. According to published specs, the 386 takes 38 cycles to multiply by a multiplier with 32 significant bits but only 9 cycles to multiply by a multiplier of 2, a performance improvement of more than four times! (My tests regularly indicate that multiplication takes 3 to 4 cycles longer than the specs indicate, but the cycle-per-bit advantage of smaller multipliers holds true nonetheless.)</P>
|
||||
<P>This highlights another interesting point: <B>MUL</B> and <B>IMUL</B> on the 386 are so fast that alternative multiplication approaches, while generally still faster, are worthwhile only in truly time-critical code.</P>
|
||||
<TABLE WIDTH="100%"><TD WIDTH="5%" VALIGN="TOP" ALIGN="LEFT"><IMG SRC="images/09-02i.jpg"><TD WIDTH="95%" VALIGN="TOP" ALIGN="LEFT"><SMALL><I>On 386SXs and uncached 386s, where code size can significantly affect performance due to instruction prefetching, the compact <B>MUL</B> and <B>IMUL</B> instructions can approach and in some cases even outperform the “optimized” alternatives.</I></SMALL>
|
||||
<TABLE WIDTH="100%"><TD WIDTH="5%" VALIGN="TOP" ALIGN="LEFT"><IMG SRC="images/i.jpg"><TD WIDTH="95%" VALIGN="TOP" ALIGN="LEFT"><SMALL><I>On 386SXs and uncached 386s, where code size can significantly affect performance due to instruction prefetching, the compact <B>MUL</B> and <B>IMUL</B> instructions can approach and in some cases even outperform the “optimized” alternatives.</I></SMALL>
|
||||
</TABLE>
|
||||
<P>All in all, <B>MUL</B> and <B>IMUL</B> are reasonable performers on the 386, no longer to be avoided in most cases—and you can help that along by arranging your code to make the smaller operand the multiplier whenever you know which operand is smaller.</P>
|
||||
<P>That 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.</P>
|
||||
|
|
@ -94,7 +94,7 @@ ADD AX,BX ;*80
|
|||
<BR><A HREF="javascript:displayWindow('images/09-01.jpg',406,306)"> --><FONT COLOR="#000077"><B>Figure 9.1</B></FONT></A> <I>Simple searching method for locating a text string.</I>
|
||||
</P>
|
||||
<P>Rob’s revelation, which he credits without explanation to Edgar Allen Poe (search nevermore?), was that by far the slowest part of the whole deal is handling <B>REPNZ SCASB</B> matches, which require checking the remainder of the string with <B>REPZ CMPS</B> and restarting <B>REPNZ SCASB</B> if no match is found.</P>
|
||||
<TABLE WIDTH="100%"><TD WIDTH="5%" VALIGN="TOP" ALIGN="LEFT"><IMG SRC="images/09-03i.jpg"><TD WIDTH="95%" VALIGN="TOP" ALIGN="LEFT"><SMALL><I>Rob points out that the number of <B>REPNZ SCASB</B> matches can easily be reduced simply by scanning for the character in the searched-for string that appears least often in the buffer being searched.</I></SMALL>
|
||||
<TABLE WIDTH="100%"><TD WIDTH="5%" VALIGN="TOP" ALIGN="LEFT"><IMG SRC="images/i.jpg"><TD WIDTH="95%" VALIGN="TOP" ALIGN="LEFT"><SMALL><I>Rob points out that the number of <B>REPNZ SCASB</B> matches can easily be reduced simply by scanning for the character in the searched-for string that appears least often in the buffer being searched.</I></SMALL>
|
||||
</TABLE>
|
||||
<P>Imagine, if you will, that you’re searching for the string “EQUAL.” By my approach, you’d use <B>REPNZ SCASB</B> 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.</P><P><BR></P>
|
||||
<CENTER>
|
||||
|
|
|
|||
Loading…
Reference in a new issue