[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 3:40 PM, David Bruant wrote:
>> 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
> OK, but I'm not sure this is a useful number, then, since these "blank
> conditions" never happen in practice.
=> I think it happens very often. While I'm writing this e-mail, "no
process" is running. About fifty processes are runnable, but not
running. They are passively waiting. My CPU is barely used.


>> 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.
>
> I'm glad you put "optimal" in quotes.... ;)
=> I'm fully aware that for a such high-level specification, talking
about optimality (and even performance !) is very relative.

>
> Is there a reason that apps that really care about this shouldn't just
> measure to see what number works best for them?
=> I agree on the fact that this is the key question to decide if my
proposal must be taken into account or not.

My point is that this number may be available very easily. For example,
in my dual-core, Linux, Firefox 3.5, the number is 2. Why spare an
information that can be useful and reliable (more than measurement at
least !) ?

I also agree on the fact that this attribute is not the most important
attribute in the world, but as the colorDepth attribute of the screen
object (http://www.w3.org/TR/cssom-view/#dom-screen-colordepth), it will
be useful to some people in some usecase.

>> 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
>
> But in the meantime you will be using them very suboptimally, no?
=> Yes and no. No one can know if they will be optimally used or not.
What you are "garanteed" (quotes again) is that in "blank conditions",
they will be optimally used (which is more or less the definition of
this number).

>> (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").
>
> Most of my apps are long-lived...
>
> -Boris