[whatwg] [WebWorkers] About the delegation example

Chris Jones cjones at mozilla.com
Fri Nov 6 23:43:59 PST 2009


David Bruant wrote:
 > On the other hand, on a 16-core processor (which doesn't exist yet, but
 > is a realistic idea for the next couple of decades), the task could be
 > executed faster with 16 workers.
 >

Maybe you mean "hardware thread" instead of "core"?  If so, the machine 
I'm writing this message on has 16 HW threads (2 CPUs x 4 cores/CPU x 2 
HW threads/core).  And there's the

http://en.wikipedia.org/wiki/Niagara_2

which has been shipping for a while now, and has 64 HW threads.  (If we 
wanted to talk GPGPUs, we'd be in the 1000s of HW threads and 100s of 
cores.  Some crazy person could make simple worker computations work on 
GPGPUs ;) .)

Drew Wilson wrote:
> I think I understand what you're trying to achieve, but it's not clear 
> to me that giving the web page a snapshot count of "free cores" is 
> actually going to do what you want, given that the number of free cores 
> can vary greatly over time.
> 

I completely agree that telling a web app the number of "free cores" 
(idle HW threads?) at a given point in time is useless, and probably 
counterproductive, even if it could be done.

Rob Ennals wrote:
 > Maybe what we really want here is some kind of parallel map operation
 > where we give the user agent an array and then say "call this function
 > on each element, using as many threads as you deem appropriate" given
 > the resources available. Each function call would logically execute in
 > it's own worker context, but to keep semantics transparent, we might
 > declare that such workers are not be allowed to send messages (other
 > than a final result) and so could not tell how many parallel workers had
 > actually been created.
 >

This.  It's just the SPMD model, ported to web workers.

Though I'm not sure what's gained by hiding the number of allocated 
parallel workers from the app, after they've been allocated.  IMHO this 
isn't a decision that should change over the duration of the computation.

If I were writing a computationally-bound webapp, I would want an 
interface like

[main thread]
   SharedWorker.parallelMap(workerfn [, ...]])

[worker thread]
   function workerfn(myThreadIndex, numberOfworkerfns [, ...]) {
      // partition problem dataset [...] based on |myThreadIndex| and 
|numberOfworkerfns|
      // compute
   }

Cheers,
Chris



More information about the whatwg mailing list