Re: [Jack-Devel] Compiling jack2 in mixed mode

On Sat, Jul 2, 2016 at 1:58 PM, Fons Adriaensen <[hidden]> wrote:

> On Sat, Jul 02, 2016 at 09:45:48AM -0400, Paul Davis wrote:
>
> > context switches are not free. their cost varies depending on the size of
> > the working set of the process (the amount of memory touched by the
> > process, notably during the JACK process() callback).
> >
> > they might vary from <10 usecs to as much as 500usecs (the lowest
> possible
> > number is dependent on your CPU; the upper bound depends on the clients)
> >
> > 100 * 100 usecs = 10msecs
> >
> > so, you've just used 10msecs of the time available for the process
> > callback. That's enormous (quite possibly larger than the actual time
> > available).
>
> True, assuming you have single linear chain of 100 clients, and
> each step involves a context switch.
>
> In practice there are two factors that mitigate this problem:
>
> 1. Parts of the graph may run in parallel. And SMP systems
>    are more or less standard today.
>

4-8 core systems are more or less standard. So this only reduces the cost
in the best possible scenario by a factor of 4-8. In more common cases, the
improvement is much less.


>
> 2. Linear chains could be in the same process. In that case,
>    depending on implementation, you don't even need a thread
>    switch.
>

Actually, I misspoke - this is already implemented. Internal clients will
be executed in the same thread if they are part of a serial chain.

IMO, the reality is that chaining together entirely independent signal
processing code is best done via plugins (internal clients, in a JACK
context), not processes. The clever hack that JACK represents is useful for
connecting small numbers of processes, but I don't believe that the design
should be used as an indication that process-level chains are the right way
to composite signal processing elements.

1467482657.23000_0.ltw:2, <CAFa_cKnh0ZdRKs6WMu34eUVP=U+UeMRvCJFO5F2vXWdsibAnkQ at mail dot gmail dot com>