[whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case

[David Bruant]

Boris Zbarsky a écrit :
> On 11/12/09 12:49 PM, David Bruant wrote:
>> =>  You're perfectly right. I reformulate the definition of "running
>> conditions" (appearing in condition 2 and 3) as :
>> "same memory available, same number of process running concurrently, no
>> other worker running working on the same document".
>
> That doesn't help that much, unfortunately.  Most simply, consider a
> quad-core chip and workers that are completely cpu-bound.  If there
> are no other processes running, the optimal number of workers is 4. 
> If there is one other process which is also completely cpu-bound
> running, the optimal number of workers is 3 (in the sense that 4 may
> well not satisfy your condition 3).  This is really the same issue as
> having one worker running, but it's some process not under the
> browser's control.
=> If you are comparing "no other processes running" and "one other
process which is also completely cpu-bound running", you are not in what
I've called "same running conditions". (because the number of concurrent
processes is different).

The condition 2 and 3 may be not well-expressed, however, the condition
1 is very important and particularly the fact that this number is
independant of the "running conditions" (which are, IMHO, totally out of
the scope of a high-level spec such as the web-workers one) and
shouldn't be determined dynamically.

I reformulate this way the conditions 2 and 3:
- In "blank conditions" (no other processes/thread running on the CPU,
enough memory to allocate the workers), running the same algorithm (an
easy delegation algorithm) has significantly better performances with
(navigator.optimalWorkerNumber) dedicated workers than with
(navigator.optimalWorkerNumber -1) dedicated workers
- In "blank conditions", running the same algorithm has no significantly
better performances with (navigator.optimalWorkerNumber+1) dedicated
workers than with (navigator.optimalWorkerNumber) dedicated workers

Just to remind, the purpose of this attribute is to decide, at the
beginning of a delegation algorithm what is the "optimal" number of
workers to divide the work in a way that is optimal regarding the
hardware, the OS and the worker implementation.
No matter the running conditions, 2 calls return the same value for the
same hardware//OS//Worker implementation.
The idea behind this property is that even if you start running the
algorithm with a lot of concurrent processes, you create a number of
workers that cannot be ran concurrently at the beginning, but you may
use optimally the ressources later (if the other processes/threads stop
running, what you cannot control, but can still hope that it happens
during the "algorithm lifetime". According to the spec, "workers are
expected to be long-lived").

Thanks for your feedback

David

>
> If, on the other hand, the workers are I/O bound (esp. network I/O
> latency bound), then the optimal number of workers can well be larger
> than the number of cores...
>
> -Boris