- 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