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
