Normal quotes

17-03.md

@@ -16,12 +16,12 @@ optimizing to do.
 The first rule of optimization is: Only optimize where it matters. Use a
 profiler, or risk making a fool of yourself. Consider Listings 17.1 and
 17.2. Where do you think the potential for significant speed-up lies?
-I’ll tell you one place where I thought there was considerable
+I'll tell you one place where I thought there was considerable
 potential—in **draw\_pixel()**. As a programmer of high-speed graphics,
 I figured any drawing function that was not only written in C/C++ but
 also recalculated the target address from scratch for each pixel would
 be among the first optimization targets. I also expected to get major
-gains out of going to a Ping-Pong arrangement so that I didn’t have to
+gains out of going to a Ping-Pong arrangement so that I didn't have to
 copy the new cellmap back to **current\_map** after calculating the next
 generation.
 
@@ -111,34 +111,34 @@ where the time actually goes in Listings 17.1 and 17.2. As you can see,
 the time taken by **draw\_pixel(),** **copy\_cells(),** and *everything*
 other than calculating the next generation is nothing more than noise.
 We could optimize these routines right down to executing
-*instantaneously,* and you know what? It wouldn’t make the slightest
+*instantaneously,* and you know what? It wouldn'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 **cell\_state()** and
 **next\_generation().**
 
   ------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  ![](images/i.jpg)   *It’s worth noting, though, that one reason **draw\_pixel()** doesn’t much affect performance is that in Listing 17.1, we’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.*
+  ![](images/i.jpg)   *It's worth noting, though, that one reason **draw\_pixel()** doesn't much affect performance is that in Listing 17.1, we'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.*
   ------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
 ### The Hazards and Advantages of Abstraction {#Heading6}
 
-How can we speed up **cell\_state()** and **next\_generation()**? I’ll
+How can we speed up **cell\_state()** and **next\_generation()**? I'll
 tell you how *not* to do it: By writing those member functions in
-assembly. It’s tempting to say that **cell\_state()** is taking all the
+assembly. It's tempting to say that **cell\_state()** is taking all the
 time, so we need to speed it up with assembly, but what we really need
 to do is figure out *why* **cell\_state()** is taking all the time, then
 address that aspect of the program directly.
 
 Once you know where you need to optimize, the one word to keep in mind
-isn’t assembly, it’s...plastics. No, actually, it’s *abstraction.*
+isn't assembly, it's...plastics. No, actually, it's *abstraction.*
 Well-written C and especially C++ 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’t even need to
+instructions. Given the cellmap member functions, you don'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’s needs, rather than implementation details.
+application's needs, rather than implementation details.
 
   ------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   ![](images/i.jpg)   *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* *is, and, without that, you have largely surrendered control over performance.*
@@ -148,10 +148,10 @@ 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 ’til doomsday, and if you have a fast
-algorithm running on top of a highly abstract programming model, you’ll
+optimize your algorithm from here 'til doomsday, and if you have a fast
+algorithm running on top of a highly abstract programming model, you'll
 almost certainly end up with a slow program. In Listing 17.1, the
-abstraction that’s killing us is that of looking at the eight neighbors
+abstraction that's killing us is that of looking at the eight neighbors
 with eight completely independent operations, requiring eight calls to
 **cell\_state()** and eight calculations of cell address and cell mask.
 In fact, given the nature of cell storage, the eight neighbors are in a