Jeff Bier’s Impulse Response—Ballooning MIPS in Multimedia Apps

Many DSP-oriented systems are composed of multiple application tasks—e.g., an audio codec, a video codec, and a networking stack. During initial product development, the system designer typically divvies up the available processor MIPS among the tasks, and assigns the tasks to various engineering teams. These teams then go off to craft their code to stay within the MIPS they've been allocated. When all of the components are finished, the tasks are integrated together and the system designer runs the whole application for the first time.

At this point, the system designer often makes an unhappy discovery.Though each task stays within its individual MIPS budget when running alone, the full application exceeds the total available MIPS. The processor, which was probably chosen to provide just enough horsepower, chokes under the load. The project’s cost and time-to-market targets go out the window, and everyone scrambles to figure out what went wrong.

The problem is that the MIPS required by a full application can't necessarily be computed as the sum of the MIPS required by the individual tasks. Sometimes it's less, which rarely causes a problem—but sometimes it's more. That's because, in a multi-tasking environment, resource contention can mean that each task runs slower than it would in a stand-alone configuration. Caches, for example, get flushed more often. History tables used for branch prediction get overwritten more frequently, so they aren't as effective. And each task's state information must be saved and restored when switching between tasks.

Furthermore, optimizations made to improve performance on one task may hurt the performance of another. For example, one team may have deliberately increased memory use to meet their MIPS target, but this decision might cause another team's task to run more slowly than expected, due to increased cache traffic. Unfortunately, optimizing each task individually does not necessarily lead to a well-optimized whole.

Depending on the system, the designer may be able to predict the impact of some of these task interactions. But many systems—such as those with pre-emptive OS's—just aren't very predictable. The best approach may be to budget MIPS generously, think about interactions up-front, integrate components early, and assume that the optimization work isn't necessarily over once the individual tasks have been optimized.