discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Combining filters


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Combining filters
Date: Sun, 15 Aug 2010 20:01:25 -0400

On Sun, Aug 15, 2010 at 12:46 AM, Brian Padalino <address@hidden> wrote:
> On Sat, Aug 14, 2010 at 8:18 PM, Marcus D. Leech <address@hidden> wrote:
>> On 08/14/2010 08:08 PM, Brian Padalino wrote:
>>> On Sat, Aug 14, 2010 at 7:59 PM, Marcus D. Leech <address@hidden> wrote:
>>>
>>>> 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?
>>>>
>>> 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.
>
> Glad I could be that somebody.
>
>>> 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.
>
> 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 :-)
>>
>> 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 Leech
>> 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


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]