You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(this is related to lib_dsp - it may have been fixed in lib_src)
The current data structure contains pointers to a 3-word and 1-word array::
typedef struct dsp_ds3_ctrl_t
{
int *in_data; // Pointer to input data (3 samples)
int *out_data; // Pointer to output data (1 sample)
...
rather than the two arrays itself::
typedef struct dsp_ds3_ctrl_t
{
int in_data[3]; // Pointer to input data (3 samples)
int out_data[1]; // Pointer to output data (1 sample)
...
The latter saves code space (no need to initialise the pointers), it saves memory space (4 words rather than 6), and best of all, you cannot forget to initialise them.
The former case optimises for a case where you move something along a buffer; something that only works if the buffer is on the same core as yourself, and not wrapped around.
Is there any good reason not to pre-allocate the arrays?
The text was updated successfully, but these errors were encountered:
This was the digimath implementation which got carried across. I thin it borrows it’s structure from the other src modules where the number of input/outputs vary.
In the case of ds3, there is no reason to not pre-allocate the arrays, other than forcing an API change.
Ed
On 1 Mar 2017, at 14:45, Henk Muller <notifications@github.com<mailto:notifications@github.com>> wrote:
(this is related to lib_dsp - it may have been fixed in lib_src)
The current data structure contains pointers to a 3-word and 1-word array::
typedef struct dsp_ds3_ctrl_t
{
int *in_data; // Pointer to input data (3 samples)
int *out_data; // Pointer to output data (1 sample)
...
rather than the two arrays itself::
typedef struct dsp_ds3_ctrl_t
{
int in_data[3]; // Pointer to input data (3 samples)
int out_data[1]; // Pointer to output data (1 sample)
...
The latter saves code space (no need to initialise the pointers), it saves memory space (4 words rather than 6), and best of all, you cannot forget to initialise them.
The former case optimises for a case where you move something along a buffer; something that only works if the buffer is on the same core as yourself, and not wrapped around.
Is there any good reason not to pre-allocate the arrays?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#18>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAmLbTTk1QLIUy_rPJeat89j2nn8vX2hks5rhYRvgaJpZM4MPvgD>.
(this is related to lib_dsp - it may have been fixed in lib_src)
The current data structure contains pointers to a 3-word and 1-word array::
typedef struct dsp_ds3_ctrl_t
{
int *in_data; // Pointer to input data (3 samples)
int *out_data; // Pointer to output data (1 sample)
...
rather than the two arrays itself::
typedef struct dsp_ds3_ctrl_t
{
int in_data[3]; // Pointer to input data (3 samples)
int out_data[1]; // Pointer to output data (1 sample)
...
The latter saves code space (no need to initialise the pointers), it saves memory space (4 words rather than 6), and best of all, you cannot forget to initialise them.
The former case optimises for a case where you move something along a buffer; something that only works if the buffer is on the same core as yourself, and not wrapped around.
Is there any good reason not to pre-allocate the arrays?
The text was updated successfully, but these errors were encountered: