Optimal way of performing multiple FFTs on a stream of data

GNU Radio
1

Hi,
This is more of a programming question than a gnuradio question.

I am writing a C++ block that takes in a stream of complex data, an N
element block {B} is chosen from the stream, this block is multiplied
with a
set {M1, M2, M3…Mn} where size of each set element is N (same as data
block) too. I want to find FFT using FFTW library on each of the
products
{B.M1, B.M2, … B.Mn} in the general_work() function. As this can be
an
intensive task can someone suggest me what could be the optimal strategy
to
do without compromising efficiency and risk losing samples that is
entering
the machine from the USRP. I was thinking about multithreading. Do you
think
this is the way to go?

Thanks,
John

2

Thanks Eric. My FFTs are not that big so I guess I will be fine.

3

On Wed, Sep 29, 2010 at 01:47:22PM -0700, John A. wrote:

the machine from the USRP. I was thinking about multithreading. Do you think
this is the way to go?

Thanks,
John

I’d measure first, and see if you’ve really got a problem.
(Premature optimization is the root of all evil.)

Note also that GNU Radio itself is multithreaded, and if you’re doing
substantial work in other blocks, your cores may already being put to
productive work.

Make sure that the version of FFTW you’re using was built with SSE
support enabled.

Installation on Unix (FFTW 3.3.10)

./configure --enable-sse --enable-float

Measure again :slight_smile:

If you do have a problem, and your cores are not already 100%
utilized, then you may want to look at using the FFTW’s suport for
multithreading (inside of the package). Note that it will only make
sense if you use one of the advanced interfaces that allows you to ask
it to compute multiple FFT’s in one call to the API. The standard
interface won’t help, unless your FFTs are seriously big – say, > 1M
points.

Eric

4

On Thu, Sep 30, 2010 at 2:54 PM, John A. [email protected]
wrote:

Thanks Eric. My FFTs are not that big so I guess I will be fine.

Yeah, FFT’s are extremely efficient. In fact, sometimes larger is
better. If you’re doing really small FFTs on the order or 16 or 32,
you might be able to get better performance by doing at 64 point FFT,
instead. Of course, measuring is the only way to know for sure.

My guess is you aren’t doing FFTs that small, so just stick with the
normal approach and, like Eric said, save the optimization for later
if you need it.

Tom