On Wed, Feb 15, 2012 at 1:27 PM, Josh Blum <j...@joshknows.com> wrote:
> > > You would have: > > > > for(size_t i = 1; i < input_items.size(); i++) > > volk_32fc_x2_multiply_32fc(is_unaligned(), out, out, > > (gr_complex*)input_items[i], noi); > > > > You halve the amount of code in gnuradio blocks which to my opinion > > makes it much more maintainable. > > > > Here is a possible solution, I dont know how viable it is. > > 1) Suppose that we have the gotten to a head or tail case where the > number of samples isnt an alignment multiple or the last call to work > ended us on a non-aligned boundary. > > 2) In an effort to re-align, the scheduler could memcpy the *smallest* > possible chunk into aligned memory, pad the length, call work, and > memcpy the result to the output buffer. > > 3) Now the next call to work will always be aligned. Also, the work > function never needs to change, and will always use the aligned call. > > I tried to implement this in gr block executor, but got confused trying > to handle all of the edge cases, like multiple IO ports with different > data types. And so, how the block would configure the scheduler in the > most generic of cases isnt clear to me. But, even if it was > oversimplified, I still think its the better way to solve 90% of the use > cases. > > Thoughts? > > -Josh Josh, I already tried this approach. It was the first thing that I went after when working on the alignment issues with the buffers. It becomes way too big of a hassle to follow through with it in the end. It only really makes sense to always move the data to an aligned buffer, but that's too expensive. Like you ran into, the corner cases and the issues of keeping track are way too much. It makes the code confusing and fragile. Also, you never want to work on the smallest amount of memory possible. This is covered in my discussion on my blog. Making arbitrarily small calls to work functions causes much more overhead than just running the unaligned version of a Volk call. I found this out pretty quickly when I started looking into things. Better to process a large chunk to get back into alignment than try to handle calls to small amounts of data. Tom
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
