Slower processors can be better

When people talk about processor benchmarks, the conversation usually ends up being all about speed. Other metrics, such as energy efficiency, are often given less attention or are completely overlooked. The unspoken assumption driving these conversations is that a faster processor is better.

For most embedded signal-processing applications, this assumption doesn't make sense. These applications usually have fixed processing requirements. Typically, the goal is to meet those requirements while minimizing cost and energy consumption. For such applications, a processor certainly needs to be fast enough to meet the processing requirements-but being significantly faster than required doesn't necessarily add value.

In fact, it's often desirable to use the slowest processor that will get the job done. All other things being equal, slower processors tend to be less expensive and less energy-hungry than faster processors. And there can be other benefits to using slower chips. For example, slower, less expensive chips often use smaller packages than high-performance chips.

Of course, some signal-processing applications demand enormous computational throughput. For such applications, it might seem obvious that a faster processor is better, but this is not always the case. Suppose, for example, that you are building a communications system with hundreds of channels. Rather than trying to cram all of those channels into one superspeedy processor, it might be better to spread the work load across several slower ones.

For one thing, a multiprocessor approach might be less expensive than a single-processor approach. Processor vendors usually charge a premium for their fastest parts, so slower parts often provide more bang for the buck than their speedy counterparts. In addition, sending all the channels through a single processor requires pumping a lot of data through that processor. This means you'll need high-bandwidth I/O interfaces and high-speed memory. These high-bandwidth components are likely to be expensive. By spreading the load across multiple processors, you can use slower, less expensive I/O and memory systems.

This is not to say that there is no advantage to having a faster processor. It is usually important to minimize the time, effort and risk associated with the development process, and having a faster processor helps meet those goals. Having a faster processor lets programmers spend less time and effort squeezing inefficiencies out of the software-meaning the product can get to market faster.

Having some processing power left over also makes it easier to reuse the design for derivative products. But this extra speed usually isn't free. You probably will have to sacrifice cost, energy efficiency or other important factors to get the extra horsepower.

In short, "Which processor is fastest?" is usually the wrong question to ask for a signal-processing application. Instead, the question should be, "Of the processors that are fast enough to get the job done, which will best meet my design goals of low cost, low power, short development time and low risk?" More often than not, the answer will be the slowest-and not the fastest-option.

Jeff Bier, the general manager of Berkeley Design Technology Inc. (www.BDTI.com), a consulting firm providing analysis and advice on DSP technology. Kenton Williston of BDTI contributed to this column.