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

Normal quotes

Browse source
This commit is contained in:
James Gregory 2013-12-30 18:34:31 +11:00
commit 18011c595a
352 changed files with 6040 additions and 6040 deletions
Download patch file Download diff file Expand all files Collapse all files

22
17-05.md
View file

@ -7,7 +7,7 @@ the member functions to compensate for the padding. Also note that the
width now has to be a multiple of eight, to facilitate the process of
copying the edges to the opposite padding bytes. We have decreased the
generality of our Game of Life implementation in exchange for better
performance. That’s a very common trade-off, as common as trading memory
performance. That's a very common trade-off, as common as trading memory
for performance. As a rule, the more general a program is, the slower it
is. A corollary is that often (not always, but often), the more heavily
optimized a program is, the more complex and the more difficult to
@ -15,17 +15,17 @@ 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
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
also have to be altered, and it’s more complex than any of the other
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
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
still taking up more than half the time. Maybe now it’s time to go to
**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?
Not hardly.
@ -37,7 +37,7 @@ then see if we can find an alternative approach that better fits the
application. It would actually have made much more sense if we had
looked for a new approach as our first optimization step, but I decided
it would be better to cover straightforward C++ optimizations at this
point, and the mind-bending stuff a little later. Right now, let’s look
point, and the mind-bending stuff a little later. Right now, let's look
at some C++ optimizations; Listing 17.4 is a C++-optimized version of
Listing 17.3.
@ -138,21 +138,21 @@ eliminating all remaining function calls and from-scratch address/mask
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
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**
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
with a small cellmap like 48x48.) We’ve sped things up by about eight
with a small cellmap like 48x48.) We've sped things up by about eight
times so far; we need to increase our speed another ten times to reach
our goal of 200x200 at 18 generations per second on a 20 MHz 386.
It’s undoubtedly possible to improve the performance of Listing 17.4
It's undoubtedly possible to improve the performance of Listing 17.4
further by fine-tuning the code, but no tremendous improvement is
possible that way.
------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
![](images/i.jpg) *Once you’ve reached the point of fine-tuning pointer usage and register variables and the like in C or C++, you’ve become compiler-dependent; you therefore might as well go to assembly and get the real McCoy.*
![](images/i.jpg) *Once you've reached the point of fine-tuning pointer usage and register variables and the like in C or C++, you've become compiler-dependent; you therefore might as well go to assembly and get the real McCoy.*
------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
------------------------ --------------------------------- --------------------