- 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>
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
worker.
For example, one way this property could be defined would be with the following
WebIDL:
[Supplemental, NoInterfaceObject]
interface NavigatorWorkerInfo {
readonly attribute int maxExecutionContexts;
}
Navigator implements NavigatorWorkerInfo;
WorkerNavigator implements NavigatorWorkerInfo;
-Rob
> -----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