[PD] how to iterate over left and right channel separately in one Pd class?

[Hans-Christoph Steiner]

If you are interested, there is still the hand-coded SIMD stuff from pd-devel:
https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-devel/v0-39

.hc

On 01/12/2013 09:34 AM, katja wrote:
> Function copy_perform8() is also eligible for SIMD processing. I used
> memcpy() because it is straightforward to use, while Pd's functions
> pointed to the wrong locations for this case. On the reverb's total
> load there is no significant performance difference.
> 
> Katja
> 
> 
> On Sat, Jan 12, 2013 at 1:00 AM, Hans-Christoph Steiner <hans at at.or.at> wrote:
>>
>> I recently learned that libc's memcpy actually uses things like SSE2 or SSSE2
>> so it can be quite fast on CPUs from the past 10 years, especially of the last
>> 5 years.
>>
>> It would be worth profiling to see if that's noticeable.
>>
>> .hc
>>
>> On 01/11/2013 05:12 PM, katja wrote:
>>> Ok so I did the ugly thing with the right channel input and output pointers:
>>>
>>> memcpy(outR, inR, vectorsize * sizeof(t_float));
>>> inR = outR;
>>>
>>> Works like a charm, thanks again.
>>>
>>> Katja
>>>
>>>
>>>
>>> On Fri, Jan 11, 2013 at 10:05 PM, Miller Puckette <msp at ucsd.edu> wrote:
>>>> copy_perform assumes the data is 4-byte aligned so might save a test
>>>> or two compared to memcopy() - but I really don't know.  I never
>>>> benchmarked the two against each other :)
>>>>
>>>> M
>>>>
>>>> On Fri, Jan 11, 2013 at 09:36:41PM +0100, katja wrote:
>>>>> Hi Miller,
>>>>>
>>>>> Thanks for the solution. The routines are in place so copying the
>>>>> right channel input to output should do it. Is there any reason to
>>>>> prefer copy_perform() over memcpy()? I'm trying to make the most
>>>>> efficient reverb for RPi & Co.
>>>>>
>>>>> Katja
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 11, 2013 at 7:57 PM, Miller Puckette <msp at ucsd.edu> wrote:
>>>>>> Hi Katja -
>>>>>>
>>>>>> There's one example of this in sigfft_dspx() - a complex FFT that 'natively'
>>>>>> works on 2 signals in-place but has to deal with various cases in which
>>>>>> buffers get re-used.  It's ugly but the basic idea is first to get the
>>>>>> inputs copied to the outputs (unless they're already there in the correct
>>>>>> order in which case nothing needs to be done) and then run the in-place
>>>>>> algorithm.
>>>>>>
>>>>>> If the algo only works out-of-place (i.e. you need 4 distinct buffers, 2
>>>>>> in and 2 out) the only way out is (at least conditionally) allocate temporary
>>>>>> copies of the inputs before writing to any outputs.
>>>>>>
>>>>>> I may be able to add an optional way tilde objects can request that output
>>>>>> buffers be distinct from input ones sometime in the future - but this is a
>>>>>> couple of steps away for me right now :)
>>>>>>
>>>>>> M
>>>>>>
>>>>>> On Fri, Jan 11, 2013 at 03:32:09PM +0100, katja wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I'm working on a Pd class with stereo channels (reverb), and the
>>>>>>> routine happens to be most efficient when iterating over the samples
>>>>>>> per channel, instead of left and right together in the perform loop.
>>>>>>> However, when doing two while loops in one object, one for left and
>>>>>>> one for right, the right channel samples get overwritten because of
>>>>>>> sample-wise in-place computation. Is this an inescapable truth? I
>>>>>>> mean, I could write a left channel class and a right channel class
>>>>>>> (actually did that to verify that it works), but it's inconvenient to
>>>>>>> use. What could be an efficient way to get them in one object?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Katja
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pd-list at iem.at mailing list
>>>>>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>>>>
>>>>> _______________________________________________
>>>>> Pd-list at iem.at mailing list
>>>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>>
>>> _______________________________________________
>>> Pd-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list