Re: [yoshimi-user] DSP Divergence Review

[Gabriel B. <gab...@gm...>]

On Tue, Aug 23, 2011 at 4:54 PM, Mark McCurry <mar...@gm...> wrote:
>> There is a lot here I don't understand, but one item raised a warning flag for
>> me, and that is the use of malloc....
> It is my understanding that the calls to fftw run the same non rt
> risks as calling malloc.
> In the case of some memory allocations in zyn, a temporary memory pool is used.
>
> The use of fftw's malloc should only differ in the memory alignment,
> which should be irrelevant in the sections of code that it was used in
> when compared to the alignment of standard new/malloc.

I agree with Mark here.  It's not for RT reasons, but for alignment reasons.

malloc() returns 8-byte aligned pointers.  IIRC fftw's malloc()
returns 16-byte aligned pointers.  The difference is that you can
directly use a 16-byte aligned pointer in SIMD operations.  I don't
see any /harm/ in doing this.  The gain is that adding low-level SIMD
code cleans up a bunch.

However, gcc's optimizer is getting lots better... obsoleting the need
for us to /write/ low-level SIMD code.  (Especially for 64-bit code.
The 32-bit optimizer is hit-or-miss in this area.)

I propose replacing it with an abstract zyn_or_yoshi_malloc() and
zyn_or_yoshi_free().  On linux it will just be a front from
posix_memalign().  On other lame-o platforms, it's not rocket science
to implement.

-gabriel