[Discuss-gnuradio] "superblock" concept / idea

[Michael Dickens]

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