Combining filters

I have an application that’s running on some fairly “spartan” hardware,
so I’m trying to find ways to make the
flow-graph more computationally efficient, so that I have more
headroom for inevitable feature creep.

Part of my flow-graph has a FIR bandpass filter, which is followed
immediately by an FFT filter. The FIR bandpass is simply
to define my passband of interest (I bring in 1MHz, but only need/want
700KHz in the middle), and the FFT filter is designed
to allow me to dynamically notch-out narrowband interferers. Is
there an efficient way to combine these two into a single
filter, that will be more computationally efficient than two filters
in series?


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

On Sat, Aug 14, 2010 at 7:59 PM, Marcus D. Leech [email protected]
wrote:

there an efficient way to combine these two into a single
filter, that will be more computationally efficient than two filters
in series?

You should be able to convolve the time domain taps of both filters to
achieve the cascaded performance of the two filters in series.

I am not sure this would really yield any better computational
results, but it’s the easiest thing that comes to mind. Switching to
fixed point for your filtering may be the best bang-for-your-buck as
long as you don’t need a massive amount of dynamic range.

I’d be interested to hear what solution you come up with.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

Good luck.

Brian

On 08/14/2010 08:08 PM, Brian P. wrote:

700KHz in the middle), and the FFT filter is designed
to allow me to dynamically notch-out narrowband interferers. Is
there an efficient way to combine these two into a single
filter, that will be more computationally efficient than two filters
in series?

You should be able to convolve the time domain taps of both filters to
achieve the cascaded performance of the two filters in series.

Oh, I knew somebody would say “just convolve 'em”, but that yields a
filter that’s
computationally the some order as the two in series, give or take.
Sigh.

I am not sure this would really yield any better computational
results, but it’s the easiest thing that comes to mind. Switching to
fixed point for your filtering may be the best bang-for-your-buck as
long as you don’t need a massive amount of dynamic range.

My impression is that floating-point performance these days, on *86
hardware,
is generally better than integer, particular with the SIMD
floating-point
instructions. The particular platform is Atom based, a D510, which is
a dual-core CPU running at about 1.7GHz. The current app is taking up
about 65% of the combined CPU, and I just want to get a little more
headroom.

I’d be interested to hear what solution you come up with.

Me too :slight_smile:

Actually, something I’d thought of would be to treat the “edges” as
multiple contiguous
notches, and run that in the FFT filter only, and eliminate the FIR
bandpass filter. But I’m not sure
I’ll get really good stop-band attenuation that way.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

On Sat, Aug 14, 2010 at 8:18 PM, Marcus D. Leech [email protected]
wrote:

to define my passband of interest (I bring in 1MHz, but only need/want
filter that’s
computationally the some order as the two in series, give or take. Sigh.

Glad I could be that somebody.

a dual-core CPU running at about 1.7GHz. The current app is taking up
about 65% of the combined CPU, and I just want to get a little more
headroom.

If you take that approach, you’d get better performance for the longer
SIMD instructions since you wouldn’t be fetching as many instructions
using the convolved filters, right? The number of operations ends up
being the same, but how quickly and how concise you can tell the
processor to do the operation is what you’re fighting now it seems.

It’s a shame it’s a D510 and doesn’t support DPPS or DPPD dot product
instruction as described here:

http://en.wikipedia.org/wiki/SSE4#SSE4.1

Either way, you may be able to pack twice as many samples if you use
16-bit samples instead of 32-bit floats:

http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions

But that ends up as a reduction in dynamic range, which I’m not sure
you can deal with.

I’d be interested to hear what solution you come up with.

Me too :slight_smile:

Actually, something I’d thought of would be to treat the “edges” as
multiple contiguous
notches, and run that in the FFT filter only, and eliminate the FIR
bandpass filter. But I’m not sure
I’ll get really good stop-band attenuation that way.

Not knowing your bandpass FIR filter, but guessing equiripple - you
could complex mix your center to baseband and do a real low-pass
filter which should be a lower order than an equivalent bandpass
equiripple - but I am making a lot of assumptions about your filters,
your data/dynamic range requirements and all sorts of other crucial
bits.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

In the end, I’m no microarchitecture expert - especially when it comes
to x86.

Good luck.

Brian

On Sun, Aug 15, 2010 at 12:46 AM, Brian P. [email protected]
wrote:

immediately by an FFT filter. The FIR bandpass is simply
Oh, I knew somebody would say “just convolve 'em”, but that yields a

using the convolved filters, right? The number of operations ends up

Actually, something I’d thought of would be to treat the “edges” as
bits.

In the end, I’m no microarchitecture expert - especially when it comes to x86.

Good luck.

Brian

I’ve done a fair amount of testing of the FIR vs. FFT filters for
speed comparisons. My main insight here is that you really should be
using an FFT filter for what you’re doing. The performance crossover
is around 22 taps for complex filters, and less than 22 taps, the FIR
filter doesn’t buy you all that much savings.

If you convolve the taps and get a longer filter, using the FFT filter
won’t cost you all that much more in performance. In fact, the
performance is fairly flat between powers of two. By that I mean,
running a 32 - 63 tap filter is roughly the same cost, and a 64 -
127 tap filter is more expensive, but within that range, it is again
roughly the same. At that point, you’re doing so much better than
the FIR filter, too.

In summary, make single filter shape by convolving the two filter taps
and then process it with the FFT filter.

Tom

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs