This is one of those things that seems obvious, but in my experience is frequently overlooked. I’ve had versions of this conversation with several coworkers over the years, so I figured it was worth writing down. The idea is that when annotating functions and methods, parameters should accept the widest type that the function or method will work correctly with, and return values should be as concrete as possible. This probably sounds familiar as it is effectively the Robustness Principle (aka Postel’s Law):

I had some ideas for some audio effects and dusted off an old Analog Devices ADSP-SC589 dev board that’s been sitting idle in a drawer for the last few years. The ADSP-SC589 is a real-time processor with 2 SHARC+ DSP cores and an ARM Cortex-A5 processor. I’ve played with rust a bit, and wanted to try it out for something embedded, and this seemed like a great opportunity. Theres no LLVM backend for the SHARC architecture, so I’m stuck with C/C++ and Analog’s compiler there, but I figured I would write the code that runs on the ARM core and orchestrates the DSPs and peripherals in rust. I had hoped that I’d find examples of others who had gone down this path but after a bit of searching I quickly realized I was on my own. Given that there isn’t any info online that I could find, I figured I’d document the process here.

In Part I and Part II of this series we developed a finite impulse response audio filter taking advantage of some of the DSP functions in the Accelerate Framework. The improvements we made in Part II were fairly straightforward, mostly replacing naive hand-coded loops with optimized implementations, taking advantage of specialized processor instructions to speed up our filter. In this installment, I’ll show you a less obvious improvement which can result in huge speedups for higher-order filters.