[whatwg] [WebWorkers] About the delegation example
bruant at enseirb-matmeca.fr
Fri Nov 6 10:50:12 PST 2009
Tab Atkins Jr. a écrit :
> On Thu, Nov 5, 2009 at 10:32 PM, David Bruant <bruant at enseirb-matmeca.fr> wrote:
>> First of all, there is a typo error in this example. The main HTML page
>> is a copy/paste of the first example ("Worker example: One-core
>> My point here is to ask for a new attribute for the navigator object
>> that could describe the "best" number of workers in a delegation use case.
>> In the delegation example, the number of workers chosen is an arbitrary
>> 10. But, in a single-core processor, having only one worker will result
>> in more or less the same running time, because at the end, each worker
>> runs on the only core. This is just a waist of memory (and maybe time
>> because of scheduling cost).
> This is not true. The naive way of coding it without workers may
> freeze the UI whenever doing heavy computation. To ensure that you
> can avoid this you have to be very explicit about breaking up your
> algorithm into chunks that you can chain together with setTimeout.
> Offloading the heavy computation to a worker allows you to code in the
> naive style (which is much easier to both code and understand) without
> the risk of UI-freeze.
> (I don't know the details, but it also seems possible that the
> context-switching between main page and worker may be cheaper than
> heavy setTimeout use. Someone else would have to confirm/deny this.)
When I say "having only one worker will result in more or less the same
running time", I mean "one worker on top of the main delegating browsing
So, I compare "the main browsing context + 10 workers" with "the main
browsing context + 1 worker" (or 16 in the next example). In all what I
say, there is no need to change the architecture of the program of to
use timers, just the JS variable "num_workers".
Sorry for the misunderstanding.
>> On the other hand, on a 16-core processor (which doesn't exist yet, but
>> is a realistic idea for the next couple of decades), the task could be
>> executed faster with 16 workers.
> Try 2 years, if AMD's press releases can be trusted. ^_^
>> The current best way to determine the number of worker that yields the
>> ressouces in the best way is to run a benchmark on an increasing number
>> of worker and stop it when the performance improvement stops.
>> I hope you will admit that this way in not acceptable.
> I'm interested in seeing if browsers can provide reasonably accurate
> estimates of this.
More information about the whatwg