- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 1 Dec 2009 07:50:41 +0000 (UTC)
On Thu, 5 Nov 2009, David Bruant 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
> computation").
Fixed.
> 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.
It's not clear to me what the best number of workers is. It's not the
number of CPUs, cores, or hardware threads, since it depends at least as
much on the system load as on the system capabilities. And it varies over
time, since the load is a function of time.
> 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.
That depends on the algorithm. If the algorithm uses a lot of data, then
a single hardware thread might be able to run two workers in the same time
as it runs one, with one worker waiting for data while the other runs
code, and with the workers trading back and forth.
Personally I would recommend basing the number of workers on the number of
shards that the input data is split into, and then relying on the UA to
avoid thrashing. I would expect UAs to notice when a script spawns a
bazillion workers, and have the UA run them in a staggered fashion, so as
to not starve the system resources. This is almost certainly needed
anyway, to prevent pages from DOSing the user's system.
> 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.
Well, again, that's not a given. If the algorithm is mostly network-bound
or disk-bound, then it might well be that running multiple workers doesn't
really gain you anything, and you might as well just do everything in one
worker. It's hard to make generalisations about this kind of thing.
> Moreover, for a totally other purpose, this attribute could be used to
> make statistics on the spread of multicore processors like the
> statistics that are already done for operating system or screen
> resolution use.
Do we really want to expose this? That seems like a minor privacy leak.
On Fri, 6 Nov 2009, Drew Wilson wrote:
>
> Exposing information that's not reliable seems worse than not exposing
> it at all, and would encourage applications to grab all available
> resources (after all, that's the purpose of the API!). And the problem
> domains that would benefit from this information (arbitrarily
> parallelizable algorithms like ray tracing) seem to be few in number.
Indeed.
On Fri, 6 Nov 2009, Rob Ennals wrote:
>
> Maybe what we really want here is some kind of parallel map operation
> where we give the user agent an array and then say "call this function
> on each element, using as many threads as you deem appropriate" given
> the resources available. Each function call would logically execute in
> it's own worker context, but to keep semantics transparent, we might
> declare that such workers are not be allowed to send messages (other
> than a final result) and so could not tell how many parallel workers had
> actually been created.
This is a reasonably good idea. It might make sense to do in v2 of Web
Workers.
I haven't added anything to Web Workers for now.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 30 November 2009 23:50:41 UTC