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

[Boris Zbarsky]

On 11/12/09 3:40 PM, David Bruant wrote:
> =>  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).

Yes, but your condition 1 is that the value returned is independent of 
running conditions....

> 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.

OK.

> 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.

> 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.... ;)

Is there a reason that apps that really care about this shouldn't just 
measure to see what number works best for them?

> 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?

> (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