W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2009

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

From: David Bruant <bruant@enseirb-matmeca.fr>
Date: Thu, 12 Nov 2009 12:40:49 -0800
Message-ID: <4AFC72D1.9020904@enseirb-matmeca.fr>
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


> 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
Received on Thursday, 12 November 2009 12:40:49 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:19 UTC