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

10
62-01.md
View file

@ -35,16 +35,16 @@ to seek out areas for improvement in Quake and, for no particular
reason, checked the number of writes performed while copying the frame
to the screen in non-page-flipped mode. The answer was 64,000. That
seemed odd, since there were 64,000 byte-sized pixels to copy, and I was
calling **memcpy()**, which of course performs copies a dword at a time
calling `memcpy()`, which of course performs copies a dword at a time
whenever possible. I thought maybe the Pentium counters report the
number of bytes written rather than the number of writes performed, but
fortunately, this time I tested my assumptions by writing an ASM routine
to copy the frame a dword at a time, without the help of **memcpy()**.
to copy the frame a dword at a time, without the help of `memcpy()`.
This time the Pentium counters reported 16,000 writes.
Whoops.
As it turns out, the **memcpy()** routine in the DOS version of our
As it turns out, the `memcpy()` routine in the DOS version of our
compiler (gcc) inexplicably copies memory a byte at a time. With my new
routine, the non-page-flipped approach suddenly became slightly *faster*
than page flipping.
@ -57,7 +57,7 @@ The second rule: When you do look foolish (and trust me, it *will*
happen if you do challenging work) have a good laugh at yourself, and
use it as a reminder of Rule \#1. I hadn't done any extra page-flipping
work yet, so I didn't waste any time due to my faulty assumption that
**memcpy()** performed a maximum-speed copy, but that was just luck. I
`memcpy()` performed a maximum-speed copy, but that was just luck. I
should have done experiments until I was sure I knew what was going on
before drawing any conclusions and acting on them.
@ -67,7 +67,7 @@ before drawing any conclusions and acting on them.
> always, always, always keep asking questions. It'll pay off big in the
> long run. If I hadn't indulged my curiosity by running the Pentium
> counter test on the copy to the screen, even though there was no
> specific reason to do so, I would never have discovered the **memcpy()**
> specific reason to do so, I would never have discovered the `memcpy()`
> problem—and by so doing I doubled the performance of the entire program
> in five minutes, a rare accomplishment indeed.