>> >> 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. >
Suppose that we didn't have a specially mapped memory. I believe the scheduler could easily ensure that contiguous chunks of memory are always passed into the work function with little overhead for both read and for write. Now, I bet there will be a slight problem when you have a block with "history" like FIR filter that needs ntaps worth of samples repeated into the next work function. So, when the scheduler has to actually wrap back around to the beginning of the buffer, it will have to memcpy nsamps to the begging of the buffer. Which shouldnt be bad when buffer size >>> history size. Its sounds possible (so stop me if I missed something big here). Basically, it would be nice to support a linear memory/buffer mode for the block executor for two reasons. 1) switch to a linear memory when allocation of mapping fails, and 2) swap out the buffer with something like a memory hole for a dsp for direct-copy. -Josh _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
