detecting when execution cannot be parallelized

[Niko Matsakis]

One of the interesting questions with Rivertrail is determining when
something cannot be parallelized. Right now there is no programmatic
way (barring measurements of timing or other tricks) to determine
whether your function was compiled in parallel. Maybe this is
desirable, as what can be parallelized will be highly implementation
dependent. On the other hand, users also need feedback.

It was suggested to me that we might add an optional callback to each of
the higher-order operations. This callback would be invoked in the case
that parallel execution failed. It would take as argument some form of
message indicating why parallel execution failed. The callback could do
whatever it likes with that message. If no callback is provided, then
the default is to ignore the message.

The role of this callback is not to implement a sequential fallback but
rather just to report the failure to execute in parallel however the
user deems appropriate. If the argument were just a string, then users
could do something like the following:

parray.map(kernel, console.log)

which would just report any failures to the console. Alternatively, if
the user wished to be sure that a function executed in parallel, they
might throw an exception in the callback:

parray.map(kernel, function(msg) { throw ...; })

Anyway, I wanted to mention this and gauge people's opinions. I think
the real question is whether we want this sort of information about
whether parallelization was successful to be so easily observable.
Another option is just to have FF log compilation failures and other
such info to the console or to whatever channels are currently used to
indicate optimization failures. I'm actually not particularly familiar
with how we do that, so I'd need to discuss that with the JS team.



Niko

[Dave Herman]

I've thought about this possibility too. it's going to be one of the most controversial questions, whatever options we consider, and tc39 will debate it hard. we should experiment but not over-invest in anything too hard to implement, since it's an area that is likely to change.

if it's not too hard to build, the callback approach is nicely general and we could use it to experiment.

Dave

_______________________________________________
dev-tech-js-engine-rivertrail mailing list
dev-tech-js-en...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rivertrail

[Herhut, Stephan A]

I don't think this kind of information is useful to the user when running a web application but might be helpful for the programmer when creating one. However, as David says, we should defer this discussion to a later time and audience.

Nonetheless, I would propose a different interface, though. My main intended use case for this information is debugging and like with ordinary JS debugging, I would prefer to throw a switch to move between modes. How about a global callback that a programmer (or debugger) can register to get (de-)optimization information? Not sure where I would hook this up, but it should allow me something like

ParallelArray.registerDeOptimizationCallBack(function (msg) {
console.log(msg);
});

and then globally get logging to the console.

Stephan

>dev-tech-js-engine-rivertrail mailing list dev-tech-js-engine-
>river...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-tech-js-engine-rivertrail
>
>_______________________________________________
>dev-tech-js-engine-rivertrail mailing list dev-tech-js-engine-
>river...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-tech-js-engine-rivertrail

[David Herman]

I disagree with your API preference, but since we agree this is the wrong place to discuss it, let's not discuss it. :)

Dave