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

Change bold code snippets to inline code blocks

Browse source
This commit is contained in:
James Gregory 2013-12-31 17:12:29 +11:00
commit 3c76d884ef
185 changed files with 1772 additions and 1772 deletions
Download patch file Download diff file Expand all files Collapse all files

18
17-05.md
View file

@ -23,16 +23,16 @@ 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's built on **set\_cell()**, **clear\_cell()**, and
**get\_cell()** is completely general; you can change the cell storage
Listing 17.1, that's built on `set_cell()`, `clear_cell()`, and
`get_cell()` 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 **count\_neighbors()** would
Listing 17.3 is harder to change because `count_neighbors()` would
also have to be altered, and it's more complex than any of the other
functions.
So, in Listing 17.3, we've gotten under the hood and changed the cellmap
format a little, and gotten impressive results. But now
**count\_neighbors()** is hard-wired for optimized counting, and it's
`count_neighbors()` is hard-wired for optimized counting, and it's
still taking up more than half the time. Maybe now it's time to go to
assembly?
@ -135,12 +135,12 @@ neighbor_count++;
```
Listing 17.4 and Listing 17.3 are functionally the same; the only
difference lies in how **next\_generation()** is implemented. (Only
**next\_generation()** is shown in Listing 17.4; the program is
difference lies in how `next_generation()` is implemented. (Only
`next_generation()` is shown in Listing 17.4; the program is
otherwise identical to Listing 17.3.) Listing 17.4 applies the following
optimizations to **next\_generation()**:
optimizations to `next_generation()`:
The neighbor-counting code is brought into **next\_generation,**
The neighbor-counting code is brought into `next_generation`,
eliminating many function calls and from-scratch address/mask
calculations; all multiplies are eliminated by using pointers and
addition; and all cells are accessed directly via pointers and masks,
@ -149,7 +149,7 @@ calculations.
The net effect of these optimizations is that Listing 17.4 is more than
twice as fast as Listing 17.3; we've achieved the desired 18 generations
per second, albeit only on a 486, and only at 96x96. (The **\#define**
per second, albeit only on a 486, and only at 96x96. (The `#define`
that enables code limiting the speed to 18 Hz, which seemed ridiculous
in Listing 17.1, is actually useful for keeping the generations from
iterating too quickly when Listing 17.4 is running on a 486, especially