On Wed, Jun 29, 2011 at 09:24, Marcus D. Leech <mle...@ripnet.com> wrote:
> ** > On 29/06/2011 12:12 PM, Johnathan Corgan wrote: > > GNU Radio achieves its streaming performance in part due to a circular > buffer design that maps the same physical memory twice in the virtual memory > map for the process, directly adjacent to each other. This allows work > function code to avoid doing any bounds checking or modular index arithmetic > operations when reading and writing its input and output buffers. Going > "off the end" of the buffer just results in accessing the start of the > buffer which is mapped into the next block of memory. Not only does this > make the code and I/O much faster, but the work function code gets a lot > simpler. > > I wonder if that assertion is generally true, or only in some cases? > Increment and test shouldn't be *that* expensive. > I'm sure the benefit varies depending on the situation, including some where there is no benefit. But modulo increments add a conditional operation for every pointer increment, which can cause a processor pipeline stall, and takes up register file space to hold the array boundaries for every input and output stream. It also forces the author of the work() function to know about how GNU Radio handles circular buffers. The double-mapped circular buffer lets the work() function treat all its inputs and outputs as linear arrays in memory, no matter the actual case. > My recollection is that sizes get ballooned outwards based on the degree > of decimation downstream from the source block, which is > a policy I've never quite gotten my head around. The FFT in my > flow-graph might get decimated by a factor of 10 or more, which given > the policy I mentioned, might lead to chunky allocations. > Ah, I think I remember this discussion a while back. It's the gr.keep_one_in_n block used to decimate the sample stream into blocks that update the FFT sink at the requested screen update rate. Decimator blocks tell the runtime their decimation ratio via set_relative_rate(). Knowing this, GNU Radio expands the buffer allocation by twice the decimation rate, to allow enough room for the upstream block thread to be simultaneously writing a full set of inputs and the downstream block thread to be reading a full set of inputs: http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/annotate/gnuradio-core/src/lib/runtime/gr_flat_flowgraph.cc#L106 > Since gr.keep_one_in_n is simply discarding n-1 input items, and doesn't need to actually process them like most decimators would, there may be an alternative way to handle this for this particular block. Johnathan
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
