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

Remove colour attributes from body and strip most of the font tags out

Browse source
This commit is contained in:
James Gregory 2013-12-30 13:57:02 +11:00
commit c1f88ddb41
362 changed files with 1632 additions and 1706 deletions
Download patch file Download diff file Expand all files Collapse all files

6
17-05.html
View file

@ -24,7 +24,7 @@
<!--CHAPTER=17//-->
<!--PAGES=335-338//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
<!--UNASSIGNED2//--></HEAD><body>
<CENTER>
<TABLE BORDER>
@ -39,7 +39,7 @@
<P>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&rsquo;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&rsquo;s built on <B>set_cell()</B>, <B>clear_cell()</B>, and <B>get_cell()</B> 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 <B>count_neighbors()</B> would also have to be altered, and it&rsquo;s more complex than any of the other functions.</P>
<P>So, in Listing 17.3, we&rsquo;ve gotten under the hood and changed the cellmap format a little, and gotten impressive results. But now <B>count_neighbors()</B> is hard-wired for optimized counting, and it&rsquo;s still taking up more than half the time. Maybe now it&rsquo;s time to go to assembly?</P>
<P>Not hardly.</P>
<H3><A NAME="Heading7"></A><FONT COLOR="#000077">Heavy-Duty C++ Optimization</FONT></H3>
<H3><A NAME="Heading7"></A>Heavy-Duty C++ Optimization</H3>
<P>Before we get to assembly, we still have to perform C<SMALL>++</SMALL> optimization, then see if we can find an alternative approach that better fits the application. It would actually have made much more sense if we had looked for a new approach as our first optimization step, but I decided it would be better to cover straightforward C<SMALL>++</SMALL> optimizations at this point, and the mind-bending stuff a little later. Right now, let&rsquo;s look at some C<SMALL>++</SMALL> optimizations; Listing 17.4 is a C<SMALL>++</SMALL>-optimized version of Listing 17.3.</P>
<P><B>LISTING 17.4 L17-4.CPP</B></P>
<!-- CODE //-->
@ -145,7 +145,7 @@ neighbor_count++;
<hr width="90%" size="1" noshade>
<div align="center">
<font face="Verdana,sans-serif" size="1">Graphics Programming Black Book &copy; 2001 Michael Abrash</font>
Graphics Programming Black Book &copy; 2001 Michael Abrash
</div>
<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
<!-- reference_subfoot = footer -->