[whatwg] [WebWorkers] About the delegation example

On Thu, Nov 5, 2009 at 10:32 PM, David Bruant <bruant at enseirb-matmeca.fr> wrote:
> Hi,
>
> 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
> computation").
>
> 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.)

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

~TJ

Received on Friday, 6 November 2009 10:29:59 UTC