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

Chapter 1 typos

Browse source
This commit is contained in:
Michael Stum 2014-01-27 22:49:56 -08:00
commit 340429d486
1 changed files with 6 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

12
src/chapter-01.md
View file

@ -254,7 +254,7 @@ requires over two and one-half minutes to checksum *one* file!
These results make it clear that it's folly to rely on your compiler's These results make it clear that it's folly to rely on your compiler's
optimization to make your programs fast. Listing 1.1 is simply poorly optimization to make your programs fast. Listing 1.1 is simply poorly
designed, and no amount of compiler optimization will compensate for designed, and no amount of compiler optimization will compensate for
that failing. To drive home the point, conListings 1.2 and 1.3, which that failing. To drive home the point, Listings 1.2 and 1.3, which
together are equivalent to Listing 1.1 except that the entire checksum together are equivalent to Listing 1.1 except that the entire checksum
loop is written in tight assembly code. The assembly language loop is written in tight assembly code. The assembly language
implementation is indeed faster than any of the C versions, as shown in implementation is indeed faster than any of the C versions, as shown in
@ -419,7 +419,7 @@ Listing 1.1.
How can we speed up Listing 1.1? It should be clear that we must somehow How can we speed up Listing 1.1? It should be clear that we must somehow
avoid invoking DOS for every byte in the file, and that means reading avoid invoking DOS for every byte in the file, and that means reading
more than one byte at a time, then buffering the data and parceling it more than one byte at a time, then buffering the data and parceling it
out for examination one byte at a time. By gosh, that's a description of out for examination one byte at a time. My gosh, that's a description of
C's stream I/O feature, whereby C reads files in chunks and buffers the C's stream I/O feature, whereby C reads files in chunks and buffers the
bytes internally, doling them out to the application as needed by bytes internally, doling them out to the application as needed by
reading them from memory rather than calling DOS. Let's try using stream reading them from memory rather than calling DOS. Let's try using stream
@ -500,7 +500,7 @@ your programs that directly affect response time. Notice, for example,
that I haven't bothered to implement a version of the checksum program that I haven't bothered to implement a version of the checksum program
entirely in assembly; Listings 1.2 and 1.6 call assembly subroutines entirely in assembly; Listings 1.2 and 1.6 call assembly subroutines
that handle the time-critical operations, but C is still used for that handle the time-critical operations, but C is still used for
checking command-line parameters, operning files, printing, and the checking command-line parameters, opening files, printing, and the
like. like.
> ![](images/i.jpg) > ![](images/i.jpg)
@ -521,7 +521,7 @@ Listing 1.4 is good, but let's see if there are other—perhaps less
obvious—ways to get the same results faster. Let's start by considering obvious—ways to get the same results faster. Let's start by considering
why Listing 1.4 is so much better than Listing 1.1. Like `read()`, why Listing 1.4 is so much better than Listing 1.1. Like `read()`,
`getc()` calls DOS to read from the file; the speed improvement of `getc()` calls DOS to read from the file; the speed improvement of
Listing 1.4 over Listing 1.1 occurs because `getc()` eads many bytes Listing 1.4 over Listing 1.1 occurs because `getc()` reads many bytes
at once via DOS, then manages those bytes for us. That's faster than at once via DOS, then manages those bytes for us. That's faster than
reading them one at a time using `read()`—but there's no reason to reading them one at a time using `read()`—but there's no reason to
think that it's faster than having our program read and manage blocks think that it's faster than having our program read and manage blocks
@ -563,7 +563,7 @@ The third reason is often fallacious. C library functions are not always
written in assembly, nor are they always particularly well-optimized. written in assembly, nor are they always particularly well-optimized.
(In fact, they're often written for *portability*, which has nothing to (In fact, they're often written for *portability*, which has nothing to
do with optimization.) What's more, they're general-purpose functions, do with optimization.) What's more, they're general-purpose functions,
and often can be outperformed by well-but-not- brilliantly-written code and often can be outperformed by well-but-not-brilliantly-written code
that is well-matched to a specific task. As an example, consider Listing that is well-matched to a specific task. As an example, consider Listing
1.5, which uses internal buffering to handle blocks of bytes at a time. 1.5, which uses internal buffering to handle blocks of bytes at a time.
Table 1.1 shows that Listing 1.5 is 2.5 to 4 times faster than Listing Table 1.1 shows that Listing 1.5 is 2.5 to 4 times faster than Listing
@ -667,7 +667,7 @@ indeed make a significant difference. Table 1.1 indicates that the
optimized version of Listing 1.5 produced by Microsoft C outperforms an optimized version of Listing 1.5 produced by Microsoft C outperforms an
unoptimized version of the same code by more than 60 percent. What's unoptimized version of the same code by more than 60 percent. What's
more, a mostly-assembly version of Listing 1.5, shown in Listings 1.6 more, a mostly-assembly version of Listing 1.5, shown in Listings 1.6
and 1.7, outperforms even the best-optimized C version of List1.5 by 26 and 1.7, outperforms even the best-optimized C version of Listing 1.5 by 26
percent. These are considerable improvements, well worth pursuing—once percent. These are considerable improvements, well worth pursuing—once
the design has been maxed out. the design has been maxed out.