On 11/18/11 5:35 PM, Andrew Wilson wrote:
On Thu, Nov 17, 2011 at 7:30 PM, Charles Pritchard <[email protected]
<mailto:[email protected]>> wrote:
On 11/17/2011 4:52 PM, Charles Pritchard wrote:
Currently, Web Workers provides a "heavy" scope for
multithreaded Web Apps to handle heavy data processing.
I'd like to draw on those specs and create a new lightweight
scope useful for various data processing tasks typically
associated with stream processing and GPUs.
Pseudo-code:
onmessage(data) { for(... data) { data[i] *= fancyness; };
postMessage(data); };
In doing this, could attach to CSS such as: img { filter:
custom(url('basicpixelworker.js')); }.
The worker may only use postMessage once, and it must send back an
array of the same size.
There are no other options, no ways to pass a message to other
contexts, no File or IDB or other APIs.
The concept here is to be very restrictive. That way, no data is
leaked, and it behaves more like a WebGL shader (think GPGPU) than
our existing web worker context.
If it's rigid, we can get very good performance, high parallelism,
and modularity. We can also get quick implementation from vendors.
And they can decide when they want to optimize.
Can you clarify what optimizations are enabled by these workers? It's
not clear to me that removing APIs makes starting up a worker any more
efficient, and I don't think significant efficiencies are enabled by
restricting workers to only sending/receiving a single message per
execution.
For the image filtering use case -- a restricted worker process would be
as secure as WebGL is for pixel shaders.
That's the main reason for removing the APIs.
I don't think significant efficiencies are enabled by single get/post
messages either. But it may make implementation of optimizations easier.
This is proposal intended for a new worker type, a subset of existing
worker behavior. It's not meant to alter existing workers.
I can't speak to performance optimizations with expertise. I'd need to
hunt down some experts in the field to give a useful information.
A sufficiently "simple" JS program could be optimized to run on a GPU
array, but that's not a short-term goal.
For working with simple parallelism:
Intel went one route, see: ParallelArray Data Structure, Elemental
Functions:
https://github.com/RiverTrail/RiverTrail/wiki/API-Design
W16 went another route using STM noting "most effective optimizations
were disabled to simplify implementation":
https://github.com/sheremetyev/w16/blob/master/README.md
I'm focused on pixel shaders as a use case. RiverTrail makes
optimization opportunities fairly explicit by introducing new data types,
W16 makes minimal changes on V8 to try to enhance parallelism.
-Charles
