Re: [Discuss-gnuradio] Parallel programming

[Michael Dickens]

I don't think there's much specialized info "out there" on this topic, since 
it's relatively standard programming; experience and knowledge are your best 
guides!  That said, there are some excellent books on parallel algorithms and 
programming out there.  Some of my favorites include (in no particular order):

"Task Scheduling for Parallel Systems" by Oliver Sinnen
"Parallel Algorithms" by Casanova, Legrand, and Robert
"The Art of Multiprocessor Programming" by Herlihy and Shavit
"Fundamentals of Sequential and Parallel Algorithms" by Berman and Paul
"Algorithms Sequential & Parallel, a Unified Approach" by Miller and Boxer

I'm also reading through and playing with the OpenCL 1.1 spec & OSX 10.6 
library right now.  Pretty cool stuff, though the documentation is a bit dry.  
I do wonder on the portability of the code ... supposed to be quite cross-OS 
compatible (Windows, Linux, OSX 10.6+, various other UNIX-y flavors) but that 
can be quite challenging.

Depending on the type of feedback you require, you might be able to use a 
standard flow-graph.  There are 2 primary types of feedback in a flow-graph 
system: data feedback and non-data feedback.  One can specialize the latter 
into control, block settings, and other types.

GNU Radio will not let you do data-feedback with data that is controlled by the 
scheduler -- meaning you cannot "connect" the data-flow output of block (A) to 
the data-flow input of any block that is before block (A) in the flow-graph 
(there are technical terms in Graph Theory for all of this; hopefully what I 
wrote is clear enough).  Although in theory one -could- do in-flow-graph 
data-feedback, it is not done in practice because this sort of feedback is 
generally done as a single item or just a few items -- which would be very 
inefficient in terms of overhead versus actual number of computations.

On the other hand, if what your block is doing is feeding back just filter 
coefficients (a type of non-data feedback), then you -might- be able to use 
either direct setting, or even better a msg_queue, between distinct blocks.  
I've never done either, but I don't see why they couldn't be made to work 
(anyone?).

For the former, you'd pass your block a reference to the prior block's method 
for setting filter coefficients (or, maybe, just the block itself depending on 
your programming style); for the latter, you'd pass in the msg_queue to your 
block to use & in the prior block you'd need to add in handling the msg_queue.  
You'd need to set default values somewhere since your block won't otherwise set 
those coefficients until after the prior block has already processed some data. 
 I think to make this case work you'd just have to be careful that no matter 
how the coefficients are set, that your block cannot generate coefficients that 
make the flow-graph "unstable" (whatever that might mean in this case).  I'd 
say that if your block works right now then this is probably the case, but it 
is possible to mess things up because there will be an added delay due to 
letting GNU Radio handle moving data around.  I'm sure someone can apply some 
discrete-time control theory here ;)

If what you are concerned with is the number of filters you're using quickly 
saturating your CPU, you'll probably want to look into the new Volk library 
and/or maybe using a GPU since both offer speed-ups depending on just how much 
computation needs to be performed & either can be more efficient than using 
generic FIR filter programmed for a CPU.

Anyway, and again, without knowing what your block actually does nor details of 
your flow-graph, that's about as much as I can comment.

On Jan 10, 2011, at 5:19 PM, jan acosta wrote:
> Yes, my block has internal data-feedback [using signal processing block 
> output to calculate new FIR filter coefficients, a trait common in adaptive 
> filters].  It runs with 1 FIR Filter pretty quickly with 1 core no problem, 
> but once I start pushing it to 5 and up, my computer can't keep up.  At 
> around 2 or 3 the core working on it is really stressed.  
> 
> I did notice that when I run example flow graphs or when I create flow graphs 
> that doesn't have any of my custom algorithms, it does really well dividing 
> the tasks to separate cores.  
> 
> Could you point a reference to this topic please?  I tried googling "internal 
> data feedback" and "data-flow feedback" with words like parallel, c++, and 
> I'm not getting good results.