Remove colour attributes from body and strip most of the font tags out
This commit is contained in:
James Gregory
parent
7e957c0bb4
commit
c1f88ddb41
362 changed files with 1632 additions and 1706 deletions
13
08-01.html
13
08-01.html
|
|
@ -24,7 +24,7 @@
|
|||
<!--CHAPTER=08//-->
|
||||
<!--PAGES=149-153//-->
|
||||
<!--UNASSIGNED1//-->
|
||||
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
|
||||
<!--UNASSIGNED2//--></HEAD><body>
|
||||
|
||||
<CENTER>
|
||||
<TABLE BORDER>
|
||||
|
|
@ -36,9 +36,8 @@
|
|||
</TABLE>
|
||||
</CENTER>
|
||||
<P><BR></P>
|
||||
<H2><A NAME="Heading1"></A><FONT COLOR="#000077">Chapter 8<BR>Speeding Up C with Assembly Language
|
||||
</FONT></H2>
|
||||
<H3><A NAME="Heading2"></A><FONT COLOR="#000077">Jumping Languages When You Know It’ll Help</FONT></H3>
|
||||
<H2><A NAME="Heading1"></A>Chapter 8<BR>Speeding Up C with Assembly Language</H2>
|
||||
<H3><A NAME="Heading2"></A>Jumping Languages When You Know It’ll Help</H3>
|
||||
<P>When I was a senior in high school, a pop song called “Seasons in the Sun,” sung by one Terry Jacks, soared up the pop charts and spent, as best I can recall, two straight weeks atop <I>Kasey Kasem’s American Top 40.</I> “Seasons in the Sun” wasn’t a particularly good song, primarily because the lyrics were silly. I’ve never understood why the song was a hit, but, as so often happens with undistinguished but popular music by forgotten one- or two-shot groups (“Don’t Pull Your Love Out on Me Baby,” “Billy Don’t Be a Hero,” <I>et al.</I>), I heard it everywhere for a month or so, then gave it not another thought for 15 years.</P>
|
||||
<P>Recently, though, I came across a review of a Rhino Records collection of obscure 1970s pop hits. Knowing that Jeff Duntemann is an aficionado of such esoterica (who do <I>you</I> know who owns an album by The Peppermint Trolley Company?), I sent the review to him. He was amused by it and, as we kicked the names of old songs around, “Seasons in the Sun” came up. I expressed my wonderment that a song that really wasn’t very good was such a big hit.</P>
|
||||
<P>“Well,” said Jeff, “I think it suffered in the translation from the French.”</P>
|
||||
|
|
@ -48,14 +47,14 @@
|
|||
</TABLE>
|
||||
<P>Apropos of which, when was the last time you heard of Terry Jacks?
|
||||
</P>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading3"></A><FONT COLOR="#000077">Billy, Don’t Be a Compiler</FONT></H4>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading3"></A>Billy, Don’t Be a Compiler</H4>
|
||||
<P>The key to optimizing C programs with assembly language is, as always, writing good assembly language code, but with an added twist. Rule 1 when converting C code to assembly is this: <I>Don’t think like a compiler.</I> That’s more easily said than done, especially when the C code you’re converting is readily available as a model and the assembly code that the compiler generates is available as well. Nevertheless, the principle of not thinking like a compiler is essential, and is, in one form or another, the basis for all that I’ll discuss below.</P>
|
||||
<P>Before I discuss Rule 1 further, let me mention rule number 0: <I>Only optimize where it matters.</I> The bulk of execution time in any program is spent in a very small portion of the code, and most code beyond that small portion doesn’t have any perceptible impact on performance. Unless you’re supremely concerned with code size (an area in which assembly-only programs can excel), I’d suggest that you write most of your code in C and reserve assembly for the truly critical sections of your code; that’s the formula that I find gives the most bang for the buck.</P>
|
||||
<P>This is not to say that complete programs shouldn’t be <I>designed</I> with optimized assembly language in mind. As you’ll see shortly, orienting your data structures towards assembly language can be a salubrious endeavor indeed, even if most of your code is in C. When it comes to actually optimizing code and/or converting it to assembly, though, do it only where it matters. Get a profiler—and use it!</P>
|
||||
<P>Also make it a point to concentrate on refining your program design and algorithmic approach at the conceptual and/or C levels before doing any assembly language optimization.</P>
|
||||
<TABLE WIDTH="100%"><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="5%"><IMG SRC="images/i.jpg"><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="95%"><SMALL><I>Assembly language optimization is the final and far from the only step in the optimization chain, and as such should be performed last; converting to assembly too soon can lock in your code before the design is optimal. At the very least, conversion to assembly tends to make future changes and debugging more difficult, slowing you down and limiting your options.</I></SMALL>
|
||||
</TABLE>
|
||||
<H3><A NAME="Heading4"></A><FONT COLOR="#000077">Don’t Call Your Functions on Me, Baby</FONT></H3>
|
||||
<H3><A NAME="Heading4"></A>Don’t Call Your Functions on Me, Baby</H3>
|
||||
<P>In order to think differently from a compiler, you must understand both what compilers and C programmers tend to do and how that differs from what assembly language does well. In this pursuit, it can be useful to examine the code your compiler generates, either by viewing the code in a debugger or by having the compiler generate an assembly language output file. (The latter is done with /Fa or /Fc in Microsoft C/C<SMALL>++</SMALL> and -S in Borland C<SMALL>++</SMALL>.)</P>
|
||||
<P>C programmers tend to modularize their code with lots of function calls. That’s good for readable, reliable, reusable code, and it allows the compiler to optimize better because it can deal with fewer variables and statements in each optimization arena—but it’s not so good when viewed from the assembly language level. Calls and returns are slow, especially in the large code model, and the pushes required to put parameters on the stack are expensive as well.</P>
|
||||
<P>What this means is that when you want to speed up a portion of a C program, you should identify the entire critical portion and move <I>all</I> of that critical portion into an assembly language function. You don’t want to move a part of the inner loop into assembly language and then call it from C every time through the loop; the function call and return overhead would be unacceptable. Carve out the critical code <I>en masse</I> and move it into assembly, and try to avoid calls and returns even in your assembly code. True, in assembly you can pass parameters in registers, but the calls and returns themselves are still slow; if the extra cycles they take don’t affect performance, then the code they’re in probably isn’t critical, and perhaps you’ve chosen to convert too much code to assembly, eh?</P><P><BR></P>
|
||||
|
|
@ -71,7 +70,7 @@
|
|||
|
||||
<hr width="90%" size="1" noshade>
|
||||
<div align="center">
|
||||
<font face="Verdana,sans-serif" size="1">Graphics Programming Black Book © 2001 Michael Abrash</font>
|
||||
Graphics Programming Black Book © 2001 Michael Abrash
|
||||
</div>
|
||||
<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
|
||||
<!-- reference_subfoot = footer -->
|
||||
|
|
|
|||
Loading…
Reference in a new issue