Taking pipeline processing to the next level

[Guillaume Piolat via Digitalmars-d]

On Monday, 5 September 2016 at 05:08:53 UTC, Manu wrote:
> A central premise of performance-oriented programming which I've
> employed my entire career, is "where there is one, there is 
> probably
> many", and if you do something to one, you should do it to many.
> With this in mind, the code I have always written doesn't tend 
> to look
> like this:
>   R manipulate(Thing thing);
>
> Instead:
>   void manipulateThings(Thing *things, size_t numThings, R 
> *output,
> size_t outputLen);
>
> Written this way for clarity. Obviously, the D equiv uses 
> slices.

To chime in, processing in chunks is indeed absolutely key for 
audio performance. Processing by element is only tolerable for 
prototyping. I don't even use slices since but usually pointers 
and length, since most slice length would be the same.

void processSamples(float* input, float* output, int samples);

Some kind of buffered input and output range concept would be 
needed there if a lazy library was to be made.

Unfortunately for this case inputs and outputs are rather 
diverse. Can't wait for a more formalized DbI introduction.

As for graphics, ae.utils.graphics usually give you a whole line 
of pixels.