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

Hi Robert,

I think using the term "execution context" here is not really 
advisable, as a JS call stack will contain a new execution 
context for every function call level. Thus, a property named
maxExecutionContexts might as well be interpreted as the 
maximum call stack depth in a single worker.

See chapter 10 and f ex 13.2.1 of:
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf

It might be better off to play on "hardware" terms like CPU,
Execution Unit, etc?

Best regards
Mike Wilson

Ennals, Robert wrote:
> 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 Thursday, 10 June 2010 10:43:11 UTC