discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] SIMD optimizations on FIR filters


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] SIMD optimizations on FIR filters
Date: Tue, 15 Jul 2003 11:01:43 -0700
User-agent: Mutt/1.4i

On Tue, Jul 15, 2003 at 03:38:46PM +0100, S?rgio Rui Silva wrote:
> >>Are you sure you're not getting it?  It only prints once.
> 
> Sorry, my mistake... I'm getting the >>> gr_fir_FFF: using
> 3DNow! message as I should...
> 
> I made some alterations to the GrFIRfilterCCF class.
> 
> -> Taps can be changed in runtime: this is something that all
> FIR and IIR filters classes should have and I added it to all
> filter classes I'm using. When I have a correct patch to them
> all I will send it.

I concur that setting the taps at runtime is useful.

The gr_fir_XXX routines already support a set_taps method. See
gr_fir_XXX_h.t  The existing qa code exercises the interface, so it's
known with high degree of probability to work correctly.

All you'll need to do is add the corresponding method to the
GrFIRfilterXXX files.

As I'm sure you've noticed, big pieces of the GrFIRfilterXXX and
gr_fir_filter_XXX stuff is generated by python code and some
pseudo templates with .t extensions.  Please be sure to patch those.


> --> The filter no longer uses the gr_fir_CCF, it now uses two
> gr_fir_FFF classes (one for the real part and other for the
> imaginary part), using this I achieved an increase of
> performance of approximately 3x. This is fine for me, but if we
> could have a gr_fir_CCF class with hand coded SIMD optimizations
> an even bigger performance increase could be achieved.

I think using two gr_fir_FFF's is a reasonable strategy.  I suggest
however, that instead of hacking GrFIRfilterCCF, that you actually
create a new subclass of gr_fir_CCF_generic, say gr_fir_CCF_dual_FFF.
This class will hold pointers to the two instances of gr_fir_FFF and
reimplement the set_taps and filter methods appropriately.  See
gr_fir_FFF_simd for the basic idea.  Then have this class be selected
"when it's the fast solution" in gr_fir_sysconfig_generic::create_gr_fir_CCF

You'll also need to add a bit of code to 
gr_fir_sysconfig_generic::get_gr_fir_CCF_info so that the benchmarking
and qa code can find it.

This preserves the existing architecture, allows for machine dependent
speedups to be added without breaking anything, and gets you the
advantage of using the dual FFF solution when there's nothing faster.

> Sergio Rui Silva

Thanks for all of your efforts!

Eric




reply via email to

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