discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Volk branch on github


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Volk branch on github
Date: Wed, 15 Feb 2012 22:12:45 -0500

On Wed, Feb 15, 2012 at 1:27 PM, Josh Blum <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]