W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

RE: [Bug 9823] New: Add "maxExecutionContexts" property with number of hardware execution contexts

From: Ennals, Robert <robert.ennals@intel.com>
Date: Tue, 8 Jun 2010 18:28:10 +0100
To: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <83D7DEC65EB438489DE261BD36F1F11F38F805CF@irsmsx503.ger.corp.intel.com>
The natural place to put this attribute seems to be on the navigator object.
This property should be made available on both the main page and within a web

For example, one way this property could be defined would be with the following

[Supplemental, NoInterfaceObject]
interface NavigatorWorkerInfo {
   readonly attribute int maxExecutionContexts;

Navigator implements NavigatorWorkerInfo;
WorkerNavigator implements NavigatorWorkerInfo;


> -----Original Message-----
> From: public-webapps-request@w3.org [mailto:public-webapps-
> request@w3.org] On Behalf Of bugzilla@jessica.w3.org
> Sent: Friday, May 28, 2010 4:09 PM
> To: public-webapps@w3.org
> Subject: [Bug 9823] New: Add "maxExecutionContexts" property with
> number of hardware execution contexts
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9823
>            Summary: Add "maxExecutionContexts" property with number of
>                     hardware execution contexts
>            Product: WebAppsWG
>            Version: unspecified
>           Platform: PC
>         OS/Version: Windows XP
>             Status: NEW
>           Severity: normal
>           Priority: P2
>          Component: Web Workers (editor: Ian Hickson)
>         AssignedTo: ian@hixie.ch
>         ReportedBy: robert.ennals@intel.com
>          QAContact: member-webapi-cvs@w3.org
>                 CC: mike@w3.org, public-webapps@w3.org
> It is likely that people will want to use the Web Workers API for
> creating
> multiple threads to perform some kind of CPU-bound computation more
> efficiently
> than they could with a single thread. In particular, Section 1.2.6
> (Delegation)
> talks about splitting a task across multiple workers in order to gain
> performance.  In this particular example, the number of workers is
> fixed at 10,
> but this is likely to be the wrong number in most cases.
> Right now, the spec gives no guidance to developers about how many
> workers they
> should use for compute-bound jobs. In the absence of such information,
> it seems
> likely that developers will do something ugly like choose a fixed
> number that
> seemed to work well on the device they tested on, attempt to identify
> which of
> a finite number of known devices the app is running on using user-agent
> sniffing, or just create far more workers than needed in the hope that
> the user
> agent will deal with the problem.
> I suggest we just add a simple "maxExecutionContexts" property with
> descriptive
> text like:
>  "This value is the maximum number of hardware execution contexts that
> may be
> available to applications running in the User Agent.  Other activity in
> the
> User Agent or on the system may be using these resources at any time
> (including
> during or after the request for information is made).  It is not the
> number of
> free, unused resources. User Agents may exclude dedicated processors
> that they
> know are not available for applications or may choose to set thread
> priorities
> low for applications that overuse system resources by starting too many
> WebWorkers on a busy system."
> "maxExecutionContexts" is not an "optimal" or "recommended" number of
> workers
> to create. If another app is using some of the cores, then the optimal
> number
> of cores may be lower. If your workers are often IO bound, then the
> optimal
> number of cores may be higher. Similarly if worker-communication costs
> are
> significant, it may not be useful to use all available cores.
> "maxExecutionContexts" is however a number that can be useful for an
> app that
> wants to choose an appropriate number of workers to create. At the
> simplest
> level, the fact that maxExecutionContexts is greater than 1 tells an
> app that
> it may be able to gain some performance from some level of parallelism,
> and the
> fact that maxExecutionContexts is a large number may indicate that it
> is wise
> for the app to split its work into finer-grain chunks than if it was
> smaller.
> It is up to an individual developer to determine how the number of
> workers they
> create corresponds to "maxExecutionContexts"; however it is likely that
> the
> availability of this number will help them make better decisions than
> they
> would  if this information was not available.
> -Rob
> --
> Configure bugmail:
> http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
Received on Tuesday, 8 June 2010 17:29:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:08 UTC