On Tue, Aug 30, 2011 at 7:45 AM, Michael Dickens
<address@hidden> wrote:
On Aug 30, 2011, at 9:34 AM, Tom Rondeau wrote:
> On Mon, Aug 29, 2011 at 8:55 PM, Marcus D. Leech <address@hidden> wrote:
>> One idea, which I credit to a conversation I had with Frank Brickle some
>> months ago, is the ability to synthesize a new block using a collection
>> of sub-blocks, and have it be "efficient". For example, in GRC, I might
>> draw a box around a collection of relatively-cheap, adjacent, sub-blocks,
>> and command GRC to produce a compiled object that is the aggregation of
>> those adjacent functions into an efficient "superblock". The idea
>> is that for simple blocks, it may be more efficient (and likely *is*) to
>> have them avoid the buffer/block-scheduling *internally*, and only have
>> them visit the block/buffer scheduler *at the edge*. The approach might
>> have GRC emit a block of C++ code that subsumes the functionality
>> of the selected adjacent blocks, and then it gets compiled and linked-in
>> to your final flow-graph. The idea could obviously be extended in
>> various ways--like integrating GPGPU support in a way that is "seamless"
>> in GRC--provide a separation between function and implementation
>> that we don't really have in Gnu Radio.
>
> That's a GREAT idea. It goes about solving a pretty serious limitation
> in the GNU Radio concept. We make blocks as small as possible. Each
> one is supposed to have one responsibility to make it as generic and
> reusable as possible. This leads to lots of data moving and buffer
> copies that are overhead. While it's a great way to develop, test,
> experiment, etc., at the end of the day, we often come down to a
> single, static flowgraph that could be optimized by coupling many of
> the blocks together.
>
> This seems to be more of a CS issue, though, so a student focused on
> communications or an EE degree isn't likely to have the skill (or
> desire) to go that deep in to something like this. But I would love to
> see someone take this up as a project.
I've been working on this issue for a bit now -- I call it "the computation granularity dilemma" because it deals with how fine a computation can or should be made. There's plenty of room for others to work on this issue too, and I don't claim to have solved it or that there is even one good solution to it :) I think, under certain conditions, I can show that this combining can be done and made to work more efficiently as a group than individually -- but I cannot prove it yet & nor do I have a working example. I cannot think of a good way to do this combining in a general fashion -- or, maybe a better way to say this is that it doesn't make sense to combine certain blocks together & then how to tell the end-user that this particular superblock will not be better than the individual blocks. I'm working with graph theory for this part, so, yes, very CS-oriented stuff :)
Traditionally, the idea of SDR was a do everything as fine-grained as possible then slowly build out from there (connecting processes / blocks / components to create an application / waveform) -- so, we have blocks for doing specific tasks, and then those are connected together to form more complicated tasks (at some extra expense in buffering and latency in computation due to the need to schedule data processing). With modern specialized processors it makes sense to take advantage of specialized instructions (e.g., FFT, iFFT, vector math, turbo decode, viterbi decode, etc as available -- think Volk here); and, as Marcus points out, sometimes we want to do away with the overhead of "buffers and scheduling" created by the SDR data-flow model -- I think these are effectively the same problem, but approached from different directions.
Because of the way GNU Radio does block definition, I think one would have to restructure things a bit -- the "work" method's code needs to be accessible to group into the larger "superblock" instead of embedded in a compiled & not installed C++ file. I think SCA / JTRS would be well-suited for this sort of work "out of the box", since it already partitions it's "work"-equivalent functions off -- and, because of the way SCA builds waveforms, these functions could be combined before compilation starts. In GNU Radio, assuming the "work" methods were available, GRC would have to compile and make available the new superblock -- not impossible, but not trivial either. Using runtime compilation (e.g., as in OpenCL) makes this problem much more tractable, too, but that would require rewriting all of GNU Radio's blocks -- again not impossible but certainly not trivial either.
Anyway, it's nice seeing this topic here! - MLD
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.
--n
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio