Re: Audio Workers - please review

On Fri, Sep 12, 2014 at 4:02 PM, Chris Wilson <cwilso@google.com> wrote:

> I do want to be clear, by the way - sorry, I'm travelling, and somewhat
> distracted - on two points:
>
> 1) I do not believe arbitrary parallelization of the graph is a good idea.
> It will be moderately difficult to examine the graph to decide that it's
> "okay" to parallelize (i.e. that there are no interconnections or other
> dependencies), and far worse, the process will needfully insert latency
> into the graph.  I believe if authors think they should parallelize their
> app, they can do that (with workers and inserting their own latency) - I've
> discussed this with a couple of pro audio app builders, and they were
> comfortable with this.  (that is to say: you don't get arbitrary
> parallelization as optimization in any other system I know of.  It has side
> effects.)
>
> 2) I'm not optimistic about trying to batch nodes together just in order
> to save some instantiation cost.  I'd far rather run this by the TAG and
> script-coord, because I feel that's not the right optimization.
>

I'd argue that it's not just "some instantiation cost"; it's an
instantiation of a full language execution context, paired with potential
network and/or disk operations and parsing and executing (JIT/AOT-cold)
script. Even if there was some way to clone a complete VM context with a
single memcpy in the state it is in before processing any onaudioprocess
events (i.e. tampering with state), the cost would not be negligible.
There's a reason node.js for example doesn't create new contexts for
modules (unless you explicitly opt-in), and for node in most cases
instantiating the contexts would only happen once when you start the
application. We, on the other hand, would be doing this all the time.

But I do agree that we should consult TAG and script-coord in this matter.