[maemo-developers] DSP SBC encoder update

[From: Siarhei Siamashka]

On Thu, Jul 10, 2008 at 6:57 PM, Simon Pickering
<S.G.Pickering at bath.ac.uk> wrote:
> No, I understood, I was just mentioning that there appear to be two
> heaps to chose from - presumably one is used by the DSP tasks (malloc is
> probably #defined as one of the CSL MEM* fns in the DSP Gateway task
> functions).

Maybe it is just clever/stupid enough to do the allocation
automatically. At least when I did some experiments with DSP before,
it was alocating DARAM memory. Surely, you might want to have better
control to put most performance critical data into DARAM, but malloc
is a standard C function and is more portable.

>> Yes, accessing SDRAM memory is extremely slow. And if you access SDRAM
>> memory using 16-bit accesses instead of 32-bit accesses, the overhead
>> doubles. So if your data processing algorithm does not deal
> exclusively
>> with 32-bit data accesses, you are better not to run it to process
> data
>> in SDRAM memory. Copying data to a temporary buffer in DARAM or
>> SARAM, processing it there and copying results back to SDRAM would be
>> faster in this case.
>
> The X[] array data type is an int32, so even accessing 32bit from SDRAM
> is still slower than using a local buffer (depending on what you need to
> do with it of course).

It depends on how many times the data is accessed. For example, if you
have some algorithm that accesses this memory location 10 times, you
would have 2 SDRAM + 10 SRAM memory accesses by using
fetch/process/store pattern vs. just 10 SDRAM memory accesses if
working with this buffer directly in SDRAM. As SDRAM is an order of
magnitude slower (decimal order, not binary), you really want to avoid
dealing with SDRAM as much as possible.