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

Deduped images

Browse source
This commit is contained in:
James Gregory 2013-12-30 12:25:34 +11:00
commit 9e52de9586
233 changed files with 128 additions and 128 deletions
Download patch file Download diff file Expand all files Collapse all files

4
17-03.html
View file

@ -96,12 +96,12 @@
<TD COLSPAN="4"><HR>
</TABLE>
<P>I was wrong. Wrong, wrong, wrong. (But at least I was smart enough to use a profiler before actually writing any new code.) Table 17.1 shows where the time actually goes in Listings 17.1 and 17.2. As you can see, the time taken by <B>draw_pixel(),</B> <B>copy_cells(),</B> and <I>everything</I> other than calculating the next generation is nothing more than noise. We could optimize these routines right down to executing <I>instantaneously,</I> and you know what? It wouldn&#146;t make the slightest perceptible difference in how fast the program runs. Given the present state of our Game of Life implementation, the only areas worth looking at for possible optimizations are <B>cell_state()</B> and <B>next_generation().</B></P>
<TABLE WIDTH="100%"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="5%"><IMG SRC="images/17-01i.jpg"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="95%"><I><SMALL>It&#146;s worth noting, though, that one reason <B>draw_pixel()</B> doesn&#146;t much affect performance is that in Listing 17.1, we&#146;re smart enough to redraw pixels only when their states change, rather than during every generation. Detecting and eliminating redundant operations is part of knowing the nature of your data, and is a potent optimization technique that will be extremely useful a little later in this chapter.</SMALL></I>
<TABLE WIDTH="100%"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="5%"><IMG SRC="images/i.jpg"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="95%"><I><SMALL>It&#146;s worth noting, though, that one reason <B>draw_pixel()</B> doesn&#146;t much affect performance is that in Listing 17.1, we&#146;re smart enough to redraw pixels only when their states change, rather than during every generation. Detecting and eliminating redundant operations is part of knowing the nature of your data, and is a potent optimization technique that will be extremely useful a little later in this chapter.</SMALL></I>
</TABLE>
<H3><A NAME="Heading6"></A><FONT COLOR="#000077">The Hazards and Advantages of Abstraction</FONT></H3>
<P>How can we speed up <B>cell_state()</B> and <B>next_generation()</B>? I&#146;ll tell you how <I>not</I> to do it: By writing those member functions in assembly. It&#146;s tempting to say that <B>cell_state()</B> is taking all the time, so we need to speed it up with assembly, but what we really need to do is figure out <I>why</I> <B>cell_state()</B> is taking all the time, then address that aspect of the program directly.</P>
<P>Once you know where you need to optimize, the one word to keep in mind isn&#146;t assembly, it&#146;s...plastics. No, actually, it&#146;s <I>abstraction.</I> Well-written C and especially C<SMALL>&#43;&#43;</SMALL> programs are highly abstract models. For example, Listing 17.1 essentially creates a new programming language in which cells are tangible things, with built-in manipulation instructions. Given the cellmap member functions, you don&#146;t even need to know the cell storage format! This is a wonderful thing, in general; it saves programming time and bugs, and frees you to work on the application&#146;s needs, rather than implementation details.</P>
<TABLE WIDTH="100%"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="5%"><IMG SRC="images/17-02i.jpg"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="95%"><I><SMALL>However, if you never look beneath the surface of the abstract model at the implementation details, you have no idea of what the true performance cost of various operations</I><I> is, and, without that, you have largely surrendered control over performance.</SMALL></I>
<TABLE WIDTH="100%"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="5%"><IMG SRC="images/i.jpg"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="95%"><I><SMALL>However, if you never look beneath the surface of the abstract model at the implementation details, you have no idea of what the true performance cost of various operations</I><I> is, and, without that, you have largely surrendered control over performance.</SMALL></I>
</TABLE>
<P>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 &#146;til doomsday, and if you have a fast algorithm running on top of a highly abstract programming model, you&#146;ll almost certainly end up with a slow program. In Listing 17.1, the abstraction that&#146;s killing us is that of looking at the eight neighbors with eight completely independent operations, requiring eight calls to <B>cell_state()</B> 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.</P><P><BR></P>
<CENTER>