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. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
