Optimization

The first rule of optimization is to optimize later. The second is to see rule one. Based on a treatise on optimizing compilers, let me tell you a small story. Marc, from Germany, wanted to optimize this line of C99 code:

for (int i=0; i < numElems; i++) theArray[i] = 0;

What we have here is an algorithm. Every algorithm has a purpose. Clearly, this algorithm's purpose is to initialize an array of integers to all zeros. Consider an alternative algorithm, also in C99:

int i=numElems; while (--i) theArray[i] = 0;

The algorithm is different, but it has the same purpose and effect. At the end, all elements of theArray are zero. Therefore, one line of code may be replaced with the other. Marc's compiler might produce different machine code for the two algorithms, and one might run a bit faster than the other. Whoopee.

Both of the above two lines of code have forced an unnecessary decision upon Marc. Should the index variable increment or decrement? The best answer is that Marc should not have to think about it. Consequently and for other reasons, Marc's best choice is this algorithm:

memset(theArray, 0, numElems);

My point is that the standard library provides a routine that performs the task well. It doesn't have to be written in C, although it may be. It will be pre-optimized once for your system. The compiler doesn't have to do any special work. But far more important, the purpose and effect of the line of code is infinitely more clear from the function call than it ever was from either explicit loop. This way is more clear. It is shorter and easier to read. It probably takes less run time than anything you might write yourself. The only downside I observed was that I had to look up the argument order. However, if I did use this routine often enough to where that was an issue, I would have learned the argument order just fine. Anyway, modern IDEs are providing hints for that.

All that being said, optimizing compilers are a great deal. They can have a big impact on run times. But please never make comparisons of optimizers based on such simple benchmarks. Spectacular performance comes soonest from having a spectacular library, finely tuned with assembler only wherever it makes a difference.

We might like to write weird numerical algorithms (say, MP3 decoding) in a high-level language and have it be really fast. The first step is always to find a good library that handles the problem already. Otherwise, if your optimizer is pretty good, then you'll be hard-pressed to do better in assembler yourself. And if your compiler doesn't optimize, then you've just found an application for the assembler. But in no event should you bother about hand-optimizing code that runs fast enough already, nor is it practical to re-invent wheels.