Deduped images

03-01.html

@@ -46,7 +46,7 @@
 <H3><A NAME="Heading3"></A><FONT COLOR="#000077">The Costs of Ignorance</FONT></H3>
 <P>As diligent as the author had been, he had nonetheless committed a cardinal sin of x86 assembly language programming: He had assumed that the information available to him was both correct and complete. While the execution times provided by Intel for its processors are indeed correct, they are incomplete; the other&#151;and often more important&#151;part of code performance is instruction <I>fetch</I> time, a topic to which I will return in later chapters.</P>
 <P>Had the author taken the time to measure the true performance of his code, he wouldn&#146;t have put his reputation on the line with relatively low-performance code. What&#146;s more, had he actually measured the performance of his code and found it to be unexpectedly slow, curiosity might well have led him to experiment further and thereby add to his store of reliable information about the CPU.</P>
-<TABLE WIDTH="100%"><TD WIDTH="5%" VALIGN="TOP"><IMG SRC="images/03-01i.jpg"><TD WIDTH="95%" VALIGN="TOP"><I><SMALL>There you have an important tenet of assembly language optimization: After crafting the best code possible, check it in action to see if it&#146;s really doing what you think it is. If it&#146;s not behaving as expected, that&#146;s all to the good, since solving mysteries is the path to knowledge. You&#146;ll learn more in this way, I assure you, than from any manual or book on assembly language.</I></SMALL>
+<TABLE WIDTH="100%"><TD WIDTH="5%" VALIGN="TOP"><IMG SRC="images/i.jpg"><TD WIDTH="95%" VALIGN="TOP"><I><SMALL>There you have an important tenet of assembly language optimization: After crafting the best code possible, check it in action to see if it&#146;s really doing what you think it is. If it&#146;s not behaving as expected, that&#146;s all to the good, since solving mysteries is the path to knowledge. You&#146;ll learn more in this way, I assure you, than from any manual or book on assembly language.</I></SMALL>
 </TABLE>
 <P><I>Assume nothing</I>. I cannot emphasize this strongly enough&#151;when you care about performance, do your best to improve the code and then <I>measure</I> the improvement. If you don&#146;t measure performance, you&#146;re just guessing, and if you&#146;re guessing, you&#146;re not very likely to write top-notch code.</P>
 <P>Ignorance about true performance can be costly. When I wrote video games for a living, I spent days at a time trying to wring more performance from my graphics drivers. I rewrote whole sections of code just to save a few cycles, juggled registers, and relied heavily on blurry-fast register-to-register shifts and adds. As I was writing my last game, I discovered that the program ran perceptibly faster if I used look-up tables instead of shifts and adds for my calculations. It <I>shouldn&#146;t</I> have run faster, according to my cycle counting, but it did. In truth, instruction fetching was rearing its head again, as it often does, and the fetching of the shifts and adds was taking as much as four times the nominal execution time of those instructions.</P>