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

[LD Zhang]

Great, these discussions actually help a lot, I am going to initially design
it to be a factor of 10 less than the theoretical limit.

There is another question: in the case of no floating point operations at
all, there must be a limit of how fast the data can stream through the
Gnuradio environment. So is the limit like 10 Msps, or like 50 Msps? A 1
Msps data stream fed through 10 parallel ports is like 10 Msps data stream,
correct?

Thanks,

LD


-----Original Message-----
From: Nathan West [mailto:address@hidden 
Sent: Thursday, July 11, 2013 3:35 PM
To: LD Zhang
Cc: Nathan West; address@hidden
Subject: Re: [Discuss-gnuradio] sustainable gnuradio MFLOPS for streaming
processing

On Thu, Jul 11, 2013 at 6:13 PM, LD Zhang <address@hidden> wrote:
> Hi, Please my comment below:
>
> 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.
>
>
>>>> I am confused: 10-tap FIR according to the above is 19 IPs, so 1M
> samples correspond to 19 MIPS, much below the 2000 MIPS limit?
> Am I missing something?
>
> LD
>

Hmm, I guess you're right. It's not too important because the actual
estimate wouldn't be close to anything close to what you would see.
The point is there is no easy answer (other than just running something to
see if it works), but you might be able to come up with a rough estimate if
you really need to and your application is really simple. You should
probably ignore my lousy attempt :-P. I came up with it on the fly...
There's also the issue of how long it takes those instructions to execute.

-Nathan