Re: [Discuss-gnuradio] sustainable gnuradio MFLOPS for streaming processing

[Nathan West]

On Thu, Jul 11, 2013 at 3:57 PM, LD Zhang <address@hidden> wrote:
> Hi Folks,
>
> The number of sustainable gnuradio processing speed – I guess in terms of
> MFLOPS – is important for designing application. Suppose I have a FIR filter
> with a number of taps operating on a streaming sample of x Msps, this would
> translate to a certain number of required MFLOPS. And this number needs to
> be below the sustainable gnuradio MFLOPS limit. Hence my question is say on
> a 1GHz processor, what is the gnuradio MFLOPS limit running on this
> processor?
>
> Thanks,
>
> LD
>

The situation is a little more complicated than this. A few considerations:
* What's the order of your FIR filter? Mo' taps mo' flops (mo' money
mo' problems?)
* As you mentioned sampling rate is also a factor.
* Although clock speed is one very easy to use metric (and an
important one!) there's more to processors than that.
* Related to the last one, is the filter all complex? all real? real
taps, complex input? All will likely have different performance.
* There's probably more than just an FIR filter in your flowgraph,
everything eats up a chunk of total processing capacity.

You can probably get a rough estimate of the lower limit of your
processors ability to do something like an FIR filter with some simple
calculations:
A 10-point FIR filter needs to do 10 multiplies and 9 additions.
Blissfully ignoring branching that's 19 instructions for each output.
So let's say we've got a simple FIR filter that outputs the same
sample rate as it inputs.

Using the table in here:
http://en.wikipedia.org/wiki/Instructions_per_second it looks like
modern CPUs clocked around 1GHz should expect between 2-5 IPS /
(1/clock speed). Pick your favorite (I'm guessing you're on older
hardware so let's go with 2). 2 * 1GHz = 2000 MIPs. So you can process
1M samples through a very poorly implemented 10-tap FIR filter. That
in itself is also a pretty poor estimate. I see Marcus just replied as
well and as he said, the best way to *know* is just to try it out on
your hardware; there's no substitute for that.