On 02/16/2012 11:39 AM, Josh Blum wrote:
>
>
> On 02/16/2012 11:32 AM, Josh Blum wrote:
>>
>>
>> On 02/16/2012 11:24 AM, Tom Rondeau wrote:
>>> On Thu, Feb 16, 2012 at 2:08 PM, Josh Blum wrote:
>>>
> Also, you never want to work on the smallest amount of memory possible.
> This is c
On Thu, Feb 16, 2012 at 1:47 PM, Josh Blum wrote:
>
>
> On 02/16/2012 01:30 PM, Douglas Geiger wrote:
> > On Thu, Feb 16, 2012 at 2:08 PM, Josh Blum wrote:
> >>
> >> Perhaps this is because you have a processor that doesn't penalize you
> >> for unaligned loads/stores.
> >>
> >> -Josh
> >
> > Wh
On 02/16/2012 01:30 PM, Douglas Geiger wrote:
> On Thu, Feb 16, 2012 at 2:08 PM, Josh Blum wrote:
>>
>> Perhaps this is because you have a processor that doesn't penalize you
>> for unaligned loads/stores.
>>
>> -Josh
>
> Which suggests this decision may need to be made on a
> per-arch/processo
On Thu, Feb 16, 2012 at 2:08 PM, Josh Blum wrote:
>
> Perhaps this is because you have a processor that doesn't penalize you
> for unaligned loads/stores.
>
> -Josh
Which suggests this decision may need to be made on a
per-arch/processor basis, and therefore it may be most appropriate for
Volk to
On 02/16/2012 11:32 AM, Josh Blum wrote:
>
>
> On 02/16/2012 11:24 AM, Tom Rondeau wrote:
>> On Thu, Feb 16, 2012 at 2:08 PM, Josh Blum wrote:
>>
>>>
Also, you never want to work on the smallest amount of memory possible.
This is covered in my discussion on my blog. Making arbitraril
On 02/16/2012 11:24 AM, Tom Rondeau wrote:
> On Thu, Feb 16, 2012 at 2:08 PM, Josh Blum wrote:
>
>>
>>> 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 mo
On Thu, Feb 16, 2012 at 2:08 PM, Josh Blum wrote:
>
> > 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
> > v
> 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 sta
On Wed, Feb 15, 2012 at 1:27 PM, Josh Blum 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 opin
On Wed, Feb 15, 2012 at 6:45 AM, Martin DvH wrote:
>
> I think it would make sense to change the volk interface by adding
> kernel calls which can handle the two alignment cases (aligned,
> unaligned).
> We would have to add a is_unaligned parameter to the volk kernel calls.
>
> The gnuradio block
> 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 sol
I think it would make sense to change the volk interface by adding
kernel calls which can handle the two alignment cases (aligned,
unaligned).
We would have to add a is_unaligned parameter to the volk kernel calls.
The gnuradio blocks would then change in the following way:
So in stead of:
if(i
On Tue, 2012-02-14 at 22:56 -0500, Tom Rondeau wrote:
> There's been a ton of work going on in getting us ready to really
> start using Volk in GNU Radio blocks. Instead of repeating myself,
> here, you can see more about the who/what/when/why/how of the changes
> here:
>
>
> http://www.trondeau
13 matches
Mail list logo
