- From: Joseph Berkovitz <joe@noteflight.com>
- Date: Fri, 12 Sep 2014 10:55:26 -0400
- To: Chris Wilson <cwilso@google.com>
- Cc: Ehsan Akhgari <ehsan@mozilla.com>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, "public-audio@w3.org" <public-audio@w3.org>
On Sep 12, 2014, at 9:02 AM, 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.) [See my later response to your followup.] > > 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. Thanks — it sounds like this is at least a partial, initial answer to my question re: Jussi’s issues about the startup costs of a worker that utilizes libraries. I would hope that there are ways to minimize the overhead of creating what amount to identical execution contexts for the same scripts. …Joe
Received on Friday, 12 September 2014 14:56:04 UTC