|Previous||Table of Contents||Next|
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 Kasey Kasems American Top 40. Seasons in the Sun wasnt a particularly good song, primarily because the lyrics were silly. Ive 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 (Dont Pull Your Love Out on Me Baby, Billy Dont Be a Hero, et al.), I heard it everywhere for a month or so, then gave it not another thought for 15 years.
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 you 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 wasnt very good was such a big hit.
Well, said Jeff, I think it suffered in the translation from the French.
Ah-ha! Mystery solved. Apparently everyone but me knew that it was translated from French, and that novelty undoubtedly made the song a big hit. The translation was also surely responsible for the sappy lyrics; dollars to donuts that the original French lyrics were stronger.
Which brings us without missing a beat to this chapters theme, speeding up C with assembly language. When you seek to speed up a C program by converting selected parts of it (generally no more than a few functions) to assembly language, make sure you end up with high-performance assembly language code, not fine-tuned C code. Compilers like Microsoft C/C++ and Watcom C are by now pretty good at fine-tuning C code, and youre not likely to do much better by taking the compilers assembly language output and tweaking it.
|To make the process of translating C code to assembly language worth the trouble, you must ignore what the compiler does and design your assembly language code from a pure assembly language perspective. With a merely adequate translation, you risk laboring mightily for little or no reward.|
Apropos of which, when was the last time you heard of Terry Jacks?
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: Dont think like a compiler. Thats more easily said than done, especially when the C code youre 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 Ill discuss below.
Before I discuss Rule 1 further, let me mention rule number 0: Only optimize where it matters. 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 doesnt have any perceptible impact on performance. Unless youre supremely concerned with code size (an area in which assembly-only programs can excel), Id suggest that you write most of your code in C and reserve assembly for the truly critical sections of your code; thats the formula that I find gives the most bang for the buck.
This is not to say that complete programs shouldnt be designed with optimized assembly language in mind. As youll 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 profilerand use it!
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.
|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.|
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++ and -S in Borland C++.)
C programmers tend to modularize their code with lots of function calls. Thats 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 arenabut its 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.
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 all of that critical portion into an assembly language function. You dont 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 en masse 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 dont affect performance, then the code theyre in probably isnt critical, and perhaps youve chosen to convert too much code to assembly, eh?
|Previous||Table of Contents||Next|