Strip comments and inline ids onto h*
This commit is contained in:
James Gregory
parent
1997a7846d
commit
0f5f617adb
362 changed files with 2519 additions and 6694 deletions
32
04-05.html
32
04-05.html
|
|
@ -10,16 +10,9 @@
|
|||
<meta name="vspubdate" content="07/01/97" />
|
||||
<meta name="vscategory" content="Web and Software Development: Game Development,Web and Software Development: Graphics and Multimedia Development" />
|
||||
|
||||
<title>Michael Abrash's Graphics Programming Black Book Special Edition: In the Lair of the Cycle-Eaters</title><!-- HEADER -->
|
||||
<!-- Empty Reference Subhead -->
|
||||
<!--ISBN=1576101746//-->
|
||||
<!--TITLE=Michael Abrash's Graphics Programming Black Book Special Edition//-->
|
||||
<!--AUTHOR=Michael Abrash//-->
|
||||
<!--PUBLISHER=The Coriolis Group, Inc.//-->
|
||||
<title>Michael Abrash's Graphics Programming Black Book Special Edition: In the Lair of the Cycle-Eaters</title>
|
||||
<meta name="chapter" content="04" />
|
||||
<meta name="pages" content="090-093" />
|
||||
<!--UNASSIGNED1//-->
|
||||
<!--UNASSIGNED2//-->
|
||||
</head>
|
||||
|
||||
<body>
|
||||
|
|
@ -41,11 +34,10 @@
|
|||
|
||||
<p>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 <b>MOV AL,0</b> instructions, and which executes at the rate of 1.81 µs per instruction. Now consider Listing 4.8, which replaces the 4-cycle <b>MOV AL,0</b> with the 3-cycle (but still 2-byte) <b>SUB AL,AL,</b> 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.</p>
|
||||
|
||||
<p><a id="Fig4"><!-- </A><A HREF="javascript:displayWindow('images/04-04.jpg',410,449 )"> --><img src="images/04-04.jpg" /><br />
|
||||
<!-- </A>
|
||||
<BR><A HREF="javascript:displayWindow('images/04-04.jpg',410,449)"> --><b>Figure 4.4</b></a> <i>Execution and instruction prefetching sequence for Listing 4.6.</i></p>
|
||||
<p><a id="Fig4"><img src="images/04-04.jpg" /><br />
|
||||
<b>Figure 4.4</b></a> <i>Execution and instruction prefetching sequence for Listing 4.6.</i></p>
|
||||
|
||||
<p><b>LISTING 4.7 LST4-7.ASM</b></p><!-- CODE //-->
|
||||
<p><b>LISTING 4.7 LST4-7.ASM</b></p>
|
||||
<pre>
|
||||
; Measures the performance of repeated MOV AL,0 instructions,
|
||||
; which take 4 cycles each according to Intel's official
|
||||
|
|
@ -57,9 +49,9 @@
|
|||
mov al,0
|
||||
endm
|
||||
call ZTimerOff
|
||||
</pre><!-- END CODE //-->
|
||||
</pre>
|
||||
|
||||
<p><b>LISTING 4.8 LST4-8.ASM</b></p><!-- CODE //-->
|
||||
<p><b>LISTING 4.8 LST4-8.ASM</b></p>
|
||||
<pre>
|
||||
; Measures the performance of repeated SUB AL,AL instructions,
|
||||
; which take 3 cycles each according to Intel's official
|
||||
|
|
@ -71,7 +63,7 @@
|
|||
sub al,al
|
||||
endm
|
||||
call ZTimerOff
|
||||
</pre><!-- END CODE //-->
|
||||
</pre>
|
||||
|
||||
<p>As you can see, it’s easy to be drawn into thinking you’re saving cycles when you’re not. You can only improve the performance of a specific bit of code by reducing the factor—either instruction fetch time or execution time, or sometimes a mix of the two—that’s limiting the performance of that code.</p>
|
||||
|
||||
|
|
@ -87,7 +79,7 @@
|
|||
|
||||
<p>What we <i>really</i> 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 <i>designed</i> 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.</p>
|
||||
|
||||
<h4 align="left"><a id="Heading12"></a>Approximating Overall Execution Times</h4>
|
||||
<h4 align="left" id="Heading12">Approximating Overall Execution Times</h4>
|
||||
|
||||
<p>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 <b>SHR</b> 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 <b>SHR</b> is executing, the fetch of the next <b>SHR</b> 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 <b>SHR</b> 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.</p>
|
||||
|
||||
|
|
@ -95,7 +87,7 @@
|
|||
|
||||
<p>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.</p>
|
||||
|
||||
<h4 align="left"><a id="Heading13"></a>What to Do about the Prefetch Queue Cycle-Eater?</h4>
|
||||
<h4 align="left" id="Heading13">What to Do about the Prefetch Queue Cycle-Eater?</h4>
|
||||
|
||||
<p>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: <i>Keep your instructions short.</i> 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.</p>
|
||||
|
||||
|
|
@ -118,10 +110,6 @@
|
|||
|
||||
<div align="center">
|
||||
Graphics Programming Black Book © 2001 Michael Abrash
|
||||
</div><!-- all of the reference materials (books) have the footer and subfoot reveresed -->
|
||||
<!-- reference_subfoot = footer -->
|
||||
<!-- reference_footer = subfoot -->
|
||||
<!-- BEGIN SUB FOOTER -->
|
||||
<!-- END FOOTER -->
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
Loading…
Reference in a new issue