[whatwg] [WebWorkers] About the delegation example

[David Bruant]

Tab Atkins Jr. a écrit :
> 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.)
>   
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
context".

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.
>
> ~TJ
>   
David