Re: [Discuss-gnuradio] "superblock" concept / idea

[Michael Dickens]

As I've thought about what you wrote, Nick, the more I like it.  As you say, it 
won't work for every block -- but there are certain blocks that would benefit 
from doing "in-place" computations, avoiding the extra 1 or 2 buffer copies per 
call to "work".  And, the implementation needs to be transparent to the 
end-user (e.g., using GRC; it should be entirely "under the hood" changes).

As for implementation in GNU Radio: I think what you're thinking of doing is 2 
parts: (1) for "in-place" type blocks, they just get input buffer(s), no output 
buffer(s) (since they re-use the input buffers for the in-place computation).  
(2) duplicate all input buffer(s) for blocks to which this block is connected 
-- thus the need for multiple writers for a given buffer.  Is this roughly the 
concept?

I certainly hope to be at the GNU Radio Conference, and would love to discuss 
this & the other "under the hood" topics with you (& others). - MLD

On Aug 30, 2011, at 11:16 AM, Nick Foster wrote:
> I've also been interested in reducing Gnuradio's memory bandwidth footprint. 
> The idea I had was to classify some blocks as capable of working "in place"; 
> i.e., writing their output to the same buffer they use for input. This way, 
> the data duplication caused by memcpying buffers around is eliminated. This 
> requires changes to gr_buffer to support multiple writers. The criteria I put 
> together for determining whether a block can work in place or not are:
> 
> 1. gr_sync_blocks only
> 2. ninputs == noutputs
> 3. block has only one parent
> 4. set_history(0)
> 
> The requirements are a little conservative; there are ways to get history in 
> there, but it requires more carefulness with the buffers. As the carefulness 
> is added restrictions can be removed. If a block fills the requirements 
> (which are evaluated in gr_flat_flowgraph), it can write its output to its 
> input gr_buffer. Multiple blocks can be chained together in the same way. I 
> put together a proof-of-concept but haven't taken it any further than that. 
> The benefit to this approach is blocks and flowgraphs don't have to be 
> rewritten, and the speedups happen entirely "under the hood", with no user 
> intervention required. Lately I haven't had time to take it further; looking 
> forward to being able to talk about this with some folks at the conference as 
> well.