- From: David Bruant <bruant@enseirb-matmeca.fr>
- Date: Thu, 12 Nov 2009 12:40:49 -0800
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
Received on Thursday, 12 November 2009 12:40:49 UTC