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

2
17-08.html
View file

@ -41,7 +41,7 @@
<P>Anyway, using the large model helps illustrate that it&#146;s the data representation and the data processing approach you choose that matter most. Optimization details like memory models and segments and in-line functions and assembly language are important but secondary. Let your mind roam creatively before you start coding. Otherwise, you may find you&#146;re writing well-tuned slow code, which is by no means the same thing as fast code.</P>
<P>Take a close look at Listing 17.5. You will see that it&#146;s quite a bit simpler than Listing 17.4. To some extent, that&#146;s because I decided to hard-wire the program to wrap around from one edge of the cellmap to the other (it&#146;s much more interesting that way), but the main reason is that it&#146;s a lot easier to work with the neighbor-count model. There&#146;s no complex mask and pointer management, and the only thing that <I>really</I> needs to be optimized is scanning for zero bytes. (And, in fact, I haven&#146;t optimized even that because it&#146;s done in a C<SMALL>&#43;&#43;</SMALL> loop; it should really be <B>REPZ SCASB.</B>)</P>
<P>In truth, none of the code in Listing 17.5 is particularly well-optimized, and, as I noted, the program must be compiled with the large model for large cellmaps. Also, of course, the entire program is still in C<SMALL>&#43;&#43;</SMALL>; note well that there&#146;s not a whit of assembly here.</P>
<TABLE WIDTH="100%"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="5%"><IMG SRC="images/17-05i.jpg"><TD VALIGN="TOP" ALIGN="LEFT" WIDTH="95%"><I><SMALL>We&#146;ve gotten more than a 30-times speedup simply by removing a little of the abstraction that C<SMALL>&#43;&#43;</SMALL> encourages, and by storing and processing the data in a manner appropriate for the typical nature of the data itself. In other words, we&#146;ve done some linear, left-brained optimization (using pointers and reducing calls) and some non-linear, right-brained optimization (understanding the real problem and listening for the creative whisper of non-obvious solutions).</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>We&#146;ve gotten more than a 30-times speedup simply by removing a little of the abstraction that C<SMALL>&#43;&#43;</SMALL> encourages, and by storing and processing the data in a manner appropriate for the typical nature of the data itself. In other words, we&#146;ve done some linear, left-brained optimization (using pointers and reducing calls) and some non-linear, right-brained optimization (understanding the real problem and listening for the creative whisper of non-obvious solutions).</SMALL></I>
</TABLE>
<P>No doubt we could get another two to five times improvement with good assembly code&#151;but that&#146;s dwarfed by a 30-times improvement, so optimization at a conceptual level <I>must</I> come first.</P>
<H4 ALIGN="LEFT"><A NAME="Heading11"></A><FONT COLOR="#000077">The Challenge That Ate My Life</FONT></H4>