Use proper lists instead of DLs with bullet points
This commit is contained in:
James Gregory
parent
500e7f5654
commit
7e957c0bb4
12 changed files with 83 additions and 83 deletions
18
01-02.html
18
01-02.html
|
|
@ -39,15 +39,15 @@
|
||||||
<H3><A NAME="Heading5"></A><FONT COLOR="#000077">Rules for Building High-Performance Code</FONT></H3>
|
<H3><A NAME="Heading5"></A><FONT COLOR="#000077">Rules for Building High-Performance Code</FONT></H3>
|
||||||
<P>We’ve got the following rules for creating high-performance software:
|
<P>We’ve got the following rules for creating high-performance software:
|
||||||
</P>
|
</P>
|
||||||
<DL>
|
<ul>
|
||||||
<DD><B>•</B> Know where you’re going (understand the objective of the software).
|
<li>Know where you’re going (understand the objective of the software).</li>
|
||||||
<DD><B>•</B> Make a big map (have an overall program design firmly in mind, so the various parts of the program and the data structures work well together).
|
<li>Make a big map (have an overall program design firmly in mind, so the various parts of the program and the data structures work well together).</li>
|
||||||
<DD><B>•</B> Make lots of little maps (design an algorithm for each separate part of the overall design).
|
<li>Make lots of little maps (design an algorithm for each separate part of the overall design).</li>
|
||||||
<DD><B>•</B> Know the territory (understand exactly how the computer carries out each task).
|
<li>Know the territory (understand exactly how the computer carries out each task).</li>
|
||||||
<DD><B>•</B> Know when it matters (identify the portions of your programs where performance matters, and don’t waste your time optimizing the rest).
|
<li>Know when it matters (identify the portions of your programs where performance matters, and don’t waste your time optimizing the rest).</li>
|
||||||
<DD><B>•</B> Always consider the alternatives (don’t get stuck on a single approach; odds are there’s a better way, if you’re clever and inventive enough).
|
<li>Always consider the alternatives (don’t get stuck on a single approach; odds are there’s a better way, if you’re clever and inventive enough).</li>
|
||||||
<DD><B>•</B> Know how to turn on the juice (optimize the code as best you know how when it <I>does</I> matter).
|
<li>Know how to turn on the juice (optimize the code as best you know how when it <I>does</I> matter).</li>
|
||||||
</DL>
|
</ul>
|
||||||
<P>Making rules is easy; the hard part is figuring out how to apply them in the real world. For my money, examining some actual working code is always a good way to get a handle on programming concepts, so let’s look at some of the performance rules in action.
|
<P>Making rules is easy; the hard part is figuring out how to apply them in the real world. For my money, examining some actual working code is always a good way to get a handle on programming concepts, so let’s look at some of the performance rules in action.
|
||||||
</P>
|
</P>
|
||||||
<H4 ALIGN="LEFT"><A NAME="Heading6"></A><FONT COLOR="#000077">Know Where You’re Going</FONT></H4>
|
<H4 ALIGN="LEFT"><A NAME="Heading6"></A><FONT COLOR="#000077">Know Where You’re Going</FONT></H4>
|
||||||
|
|
|
||||||
12
04-01.html
12
04-01.html
File diff suppressed because one or more lines are too long
12
04-10.html
12
04-10.html
|
|
@ -54,12 +54,12 @@
|
||||||
<H4 ALIGN="LEFT"><A NAME="Heading23"></A><FONT COLOR="#000077">Cycle-Eaters: A Summary</FONT></H4>
|
<H4 ALIGN="LEFT"><A NAME="Heading23"></A><FONT COLOR="#000077">Cycle-Eaters: A Summary</FONT></H4>
|
||||||
<P>We’ve covered a great deal of sophisticated material in this chapter, so don’t feel bad if you haven’t understood everything you’ve read; it will all become clear from further reading, especially once you study, time, and tune code that you have written yourself. What’s really important is that you come away from this chapter understanding that on the 8088:
|
<P>We’ve covered a great deal of sophisticated material in this chapter, so don’t feel bad if you haven’t understood everything you’ve read; it will all become clear from further reading, especially once you study, time, and tune code that you have written yourself. What’s really important is that you come away from this chapter understanding that on the 8088:
|
||||||
</P>
|
</P>
|
||||||
<DL>
|
<ul>
|
||||||
<DD><B>•</B> The 8-bit bus cycle-eater causes each access to a word-sized operand to be 4 cycles longer than an equivalent access to a byte-sized operand.
|
<li>The 8-bit bus cycle-eater causes each access to a word-sized operand to be 4 cycles longer than an equivalent access to a byte-sized operand.</li>
|
||||||
<DD><B>•</B> The prefetch queue cycle-eater can cause instruction execution times to be as much as four times longer than the officially documented cycle times.
|
<li>The prefetch queue cycle-eater can cause instruction execution times to be as much as four times longer than the officially documented cycle times.</li>
|
||||||
<DD><B>•</B> The DRAM refresh cycle-eater slows most PC code, with performance reductions ranging as high as 8.33 percent.
|
<li>The DRAM refresh cycle-eater slows most PC code, with performance reductions ranging as high as 8.33 percent.</li>
|
||||||
<DD><B>•</B> The display adapter cycle-eater typically doubles and can more than triple the length of the standard 4-cycle access to display memory, with intensive display memory access suffering most.
|
<li>The display adapter cycle-eater typically doubles and can more than triple the length of the standard 4-cycle access to display memory, with intensive display memory access suffering most.</li>
|
||||||
</DL>
|
</ul>
|
||||||
<P>This basic knowledge about cycle-eaters puts you in a good position to understand the results reported by the Zen timer, and that means that you’re well on your way to writing high-performance assembler code.
|
<P>This basic knowledge about cycle-eaters puts you in a good position to understand the results reported by the Zen timer, and that means that you’re well on your way to writing high-performance assembler code.
|
||||||
</P>
|
</P>
|
||||||
<H4 ALIGN="LEFT"><A NAME="Heading24"></A><FONT COLOR="#000077">What Does It All Mean?</FONT></H4>
|
<H4 ALIGN="LEFT"><A NAME="Heading24"></A><FONT COLOR="#000077">What Does It All Mean?</FONT></H4>
|
||||||
|
|
|
||||||
14
08-02.html
14
08-02.html
|
|
@ -77,13 +77,13 @@ jz Match
|
||||||
<P>More on this shortly.
|
<P>More on this shortly.
|
||||||
</P>
|
</P>
|
||||||
<P>To recap, here are some things to look for when striving to convert C code into optimized assembly language:</P>
|
<P>To recap, here are some things to look for when striving to convert C code into optimized assembly language:</P>
|
||||||
<DL>
|
<ul>
|
||||||
<DD><B>•</B> Move the entire performance-critical section into a single assembly language function.
|
<li>Move the entire performance-critical section into a single assembly language function.</li>
|
||||||
<DD><B>•</B> Don’t use calls or stack frame accesses inside the critical code, if possible, and avoid unnecessary memory accesses of any kind.
|
<li>Don’t use calls or stack frame accesses inside the critical code, if possible, and avoid unnecessary memory accesses of any kind.</li>
|
||||||
<DD><B>•</B> Change segments as infrequently as possible.
|
<li>Change segments as infrequently as possible.</li>
|
||||||
<DD><B>•</B> Optimize in terms of what assembly does well, <I>not</I> in terms of fine-tuning compiled C code.
|
<li>Optimize in terms of what assembly does well, <I>not</I> in terms of fine-tuning compiled C code.</li>
|
||||||
<DD><B>•</B> Change the rules to the benefit of assembly, if necessary; for example, reorganize data structto allow efficient assembly language processing.
|
<li>Change the rules to the benefit of assembly, if necessary; for example, reorganize data structto allow efficient assembly language processing.</li>
|
||||||
</DL>
|
</ul>
|
||||||
<P>That said, let me show some of these precepts in action.
|
<P>That said, let me show some of these precepts in action.
|
||||||
</P>
|
</P>
|
||||||
<H4 ALIGN="LEFT"><A NAME="Heading9"></A><FONT COLOR="#000077">A C-to-Assembly Case Study</FONT></H4>
|
<H4 ALIGN="LEFT"><A NAME="Heading9"></A><FONT COLOR="#000077">A C-to-Assembly Case Study</FONT></H4>
|
||||||
|
|
|
||||||
22
11-03.html
22
11-03.html
|
|
@ -40,19 +40,19 @@
|
||||||
</P>
|
</P>
|
||||||
<P>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.)</P>
|
<P>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.)</P>
|
||||||
<P>To summarize:</P>
|
<P>To summarize:</P>
|
||||||
<DL>
|
<ul>
|
||||||
<DD><B>•</B> Memory-accessing instructions don’t run at their official speeds on non-zero-wait-state 286/386 computers.
|
<li>Memory-accessing instructions don’t run at their official speeds on non-zero-wait-state 286/386 computers.</li>
|
||||||
<DD><B>•</B> The prefetch queue cycle-eater reduces performance on 286/386 computers, particularly when non-zero-wait-state memory is used.
|
<li>The prefetch queue cycle-eater reduces performance on 286/386 computers, particularly when non-zero-wait-state memory is used.</li>
|
||||||
<DD><B>•</B> Branches often execute at less than their rated speeds on the 286 and 386 since the prefetch queue is emptied.
|
<li>Branches often execute at less than their rated speeds on the 286 and 386 since the prefetch queue is emptied.</li>
|
||||||
<DD><B>•</B> The extent to which the prefetch queue and wait states affect performance varies from one 286/386 computer to another, making precise optimization impossible.
|
<li>The extent to which the prefetch queue and wait states affect performance varies from one 286/386 computer to another, making precise optimization impossible.</li>
|
||||||
</DL>
|
</ul>
|
||||||
<P>What’s to be learned from all this? Several things:
|
<P>What’s to be learned from all this? Several things:
|
||||||
</P>
|
</P>
|
||||||
<DL>
|
<ul>
|
||||||
<DD><B>•</B> Keep your instructions short.
|
<li>Keep your instructions short.</li>
|
||||||
<DD><B>•</B> Keep it in the registers; avoid memory, since memory generally can’t keep up with the processor.
|
<li>Keep it in the registers; avoid memory, since memory generally can’t keep up with the processor.</li>
|
||||||
<DD><B>•</B> Don’t jump.
|
<li>Don’t jump.</li>
|
||||||
</DL>
|
</ul>
|
||||||
<P>Of course, those are exactly the rules that apply to 8088 optimization as well. Isn’t it convenient that the same general rules apply across the board?
|
<P>Of course, those are exactly the rules that apply to 8088 optimization as well. Isn’t it convenient that the same general rules apply across the board?
|
||||||
</P>
|
</P>
|
||||||
<H4 ALIGN="CENTER"><A NAME="Heading7"></A><FONT COLOR="#000077">Data Alignment</FONT></H4>
|
<H4 ALIGN="CENTER"><A NAME="Heading7"></A><FONT COLOR="#000077">Data Alignment</FONT></H4>
|
||||||
|
|
|
||||||
File diff suppressed because one or more lines are too long
10
17-06.html
10
17-06.html
|
|
@ -38,11 +38,11 @@
|
||||||
<P><BR></P>
|
<P><BR></P>
|
||||||
<P>We’re still not ready for assembly, though; what we need is a new perspective that lends itself to vastly better performance in C<SMALL>++</SMALL>. The Life program in the next section is <I>three to seven times</I> faster than Listing 17.4—and it’s still in C<SMALL>++</SMALL>.</P>
|
<P>We’re still not ready for assembly, though; what we need is a new perspective that lends itself to vastly better performance in C<SMALL>++</SMALL>. The Life program in the next section is <I>three to seven times</I> faster than Listing 17.4—and it’s still in C<SMALL>++</SMALL>.</P>
|
||||||
<P>How is this possible? Here are some hints:</P>
|
<P>How is this possible? Here are some hints:</P>
|
||||||
<DL>
|
<ul>
|
||||||
<DD><B>•</B> After a few dozen generations, most of the cellmap consists of cells in the off state.
|
<li>After a few dozen generations, most of the cellmap consists of cells in the off state.</li>
|
||||||
<DD><B>•</B> There are many possible cellmap representations other than one bit-per-pixel.
|
<li>There are many possible cellmap representations other than one bit-per-pixel.</li>
|
||||||
<DD><B>•</B> Cells change state relatively infrequently.
|
<li>Cells change state relatively infrequently.</li>
|
||||||
</DL>
|
</ul>
|
||||||
<H3><A NAME="Heading8"></A><FONT COLOR="#000077">Bringing In the Right Brain</FONT></H3>
|
<H3><A NAME="Heading8"></A><FONT COLOR="#000077">Bringing In the Right Brain</FONT></H3>
|
||||||
<P>In the previous section, we saw how a C<SMALL>++</SMALL> program could be sped up about eight times simply by rearranging the data and code in straightforward ways. Now we’re going to see how right-brain non-linear optimization can speed things up by another four times—and make the code <I>simpler.</I></P>
|
<P>In the previous section, we saw how a C<SMALL>++</SMALL> program could be sped up about eight times simply by rearranging the data and code in straightforward ways. Now we’re going to see how right-brain non-linear optimization can speed things up by another four times—and make the code <I>simpler.</I></P>
|
||||||
<P>Now <I>that’s</I> Zen code optimization.</P>
|
<P>Now <I>that’s</I> Zen code optimization.</P>
|
||||||
|
|
|
||||||
16
17-08.html
16
17-08.html
File diff suppressed because one or more lines are too long
16
38-02.html
16
38-02.html
File diff suppressed because one or more lines are too long
10
39-01.html
10
39-01.html
File diff suppressed because one or more lines are too long
14
52-01.html
14
52-01.html
File diff suppressed because one or more lines are too long
14
62-03.html
14
62-03.html
|
|
@ -38,13 +38,13 @@
|
||||||
<P><BR></P>
|
<P><BR></P>
|
||||||
<H4 ALIGN="LEFT"><A NAME="Heading4"></A><FONT COLOR="#000077">The Rendering Pipeline</FONT></H4>
|
<H4 ALIGN="LEFT"><A NAME="Heading4"></A><FONT COLOR="#000077">The Rendering Pipeline</FONT></H4>
|
||||||
<P>Conceptually rendering from a BSP tree really is that simple, but the implementation is a bit more complicated. The full rendering pipeline, as coordinated by <B>UpdateWorld()</B>, is this:</P>
|
<P>Conceptually rendering from a BSP tree really is that simple, but the implementation is a bit more complicated. The full rendering pipeline, as coordinated by <B>UpdateWorld()</B>, is this:</P>
|
||||||
<DL>
|
<ul>
|
||||||
<DD><B>•</B> Update the current location.
|
<li>Update the current location.</li>
|
||||||
<DD><B>•</B> Transform all wall endpoints into viewspace (the world as seen from the current location with the current viewing angle).
|
<li>Transform all wall endpoints into viewspace (the world as seen from the current location with the current viewing angle).</li>
|
||||||
<DD><B>•</B> Clip all walls to the view pyramid.
|
<li>Clip all walls to the view pyramid.</li>
|
||||||
<DD><B>•</B> Project wall vertices to screen coordinates.
|
<li>Project wall vertices to screen coordinates.</li>
|
||||||
<DD><B>•</B> Walk the walls back to front, and for each wall that lies at least partially in the view pyramid, perform backface culling (skip walls facing away from the viewer), and draw the wall if it’s not culled.
|
<li>Walk the walls back to front, and for each wall that lies at least partially in the view pyramid, perform backface culling (skip walls facing away from the viewer), and draw the wall if it’s not culled.</li>
|
||||||
</DL>
|
</ul>
|
||||||
<P>Next, we’ll look at each part of the pipeline more closely. The pipeline is too complex for me to be able to discuss each part in complete detail. Some sources for further reading are <I>Computer Graphics</I>, by Foley and van Dam (ISBN 0-201-12110-7), and the <I>DDJ Essential Books on Graphics Programming</I> CD.</P>
|
<P>Next, we’ll look at each part of the pipeline more closely. The pipeline is too complex for me to be able to discuss each part in complete detail. Some sources for further reading are <I>Computer Graphics</I>, by Foley and van Dam (ISBN 0-201-12110-7), and the <I>DDJ Essential Books on Graphics Programming</I> CD.</P>
|
||||||
<H3><A NAME="Heading5"></A><FONT COLOR="#000077">Moving the Viewer</FONT></H3>
|
<H3><A NAME="Heading5"></A><FONT COLOR="#000077">Moving the Viewer</FONT></H3>
|
||||||
<P>The sample BSP program performs first-person rendering; that is, it renders the world as seen from your eyes as you move about. The rate of movement is controlled by key-handling code that’s not shown in Listing 62.1; however, the variables set by the key-handling code are used in <B>UpdateViewPos()</B> to bring the current location up to date.</P>
|
<P>The sample BSP program performs first-person rendering; that is, it renders the world as seen from your eyes as you move about. The rate of movement is controlled by key-handling code that’s not shown in Listing 62.1; however, the variables set by the key-handling code are used in <B>UpdateViewPos()</B> to bring the current location up to date.</P>
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue