Optimization theory  (Page 2/2)

Library routines

If the algorithm uses common mathematical operations, such as the cosine and FFT operations, it is usuallywise to use existing library routines instead of "reinventing the wheel." As many library routines are readily available from DSPmanufacturers and over the internet, the first factor to consider in using a library is its license: do you have permission to use it inyour application? Libraries can often be used freely for educational and research purposes, but any other use requires inspectionof the library license.

The second factor to consider is the design goal of the library: was it designed for speed or low memory usage? Typically speed can bebought with more memory and vice-versa, so when selecting a library it is important to decidewhich budget (speed or memory) is more important with respect to the routine.

Compiler optimization

Recall that the basic operation of a C compiler is to translate C source code into assembly instructions and then into an executable.

"Compiler optimization is used to improve the efficiency (in terms ofrunning time or resource usage) of the executables output by a compiler. These techniques allow programmers to write source code in a straightforward manner, expressing their intentions clearly,while allowing the computer to make choices about implementation details that lead to efficient execution. Contrary to what the termmight imply, this rarely results in executables that are perfectly "optimal" by any measure, only executables that are much improvedcompared to direct translation of the programmer's original source."

An optimizing compiler traditionally groups optimizations into phases . Each phase contains a series of optimizations (or transformations) that are performed in a fixed order.These phases are usually turned on with command-line flags such as -O1 , -O2 , etc. Each flag indicates an optimization "level" where the level includes all of the lower levels. At higheroptimization levels bugs in the code are sometimes introduced, so it is important to check the behavior of a compiler-optimized programagainst the reference implementation. Keep the highest optimization level that produces accurate code.

At this point the compiled code should be checked against the budgetary constraints. Is it fast enough? Does it fit in available memory?Total memory usage is placed in a file produced by the compiler (sometimes a command-line flag is needed for this). Speed can bemeasured in a couple of ways. The most common method is the use of a profiler . A profiler tracks the performance of the program, providing data on how many times each function is called, as well ashow much time each function takes in terms of cycles and percentages of total program cycles. A simulator also allows clock cycles to bemeasured, typically by allowing the user to place breakpoints around sections of code to be measured. If the speed and memory properties ofthe compiled code fit the budget, optimization is finished. If not, some of the routines must be hand-written in assembly.

Write key assembly routines manually

Finally, if the budget cannot be met with the other optimization techniques some routines must be written in assembly. Manually-writtenassembly code is usually the most efficient, but it is labor-intensive and it is not portable to other architectures.Therefore it is done as a last resort and only on routines that absolutely require it for budget constraints to be met. This is doneby rewriting the routine that consumes the largest portion of the budget, followed by the next largest budget-consuming routine and soon until the budget is met. It should be noted that this step is almost always required in embedded applications ascurrent state-of-the-art C compilers and optimizers do not produce sufficiently fast and/or small code.

If meeting the budget is unexpectedly difficult, remember that no compiler optimization or assembler can effectively overcome a poor algorithm design or implementation. If you are confident that your implentation is fast and accurate, then the budget may be too tight for the application. Either some parts ofthe application must be removed (extra "features", for example) or an architecture with more resources must be used.