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: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 10 Jun 2010 10:04:46 -0700
Message-ID: <AANLkTink6-mg28qdvcROh9uPUMQ5cUlEgqQlxMctaWfO@mail.gmail.com>
To: Mike Wilson <mikewse@hotmail.com>
Cc: "Ennals, Robert" <robert.ennals@intel.com>, public-webapps@w3.org
For what it's worth, it's unlikely that we at mozilla will implement
this anytime soon, if at all. We're currently working on trying to
reduce the ability to fingerprint [1] and this would be a step in the
wrong direction for us. This is based on discussions with security
folks here, so it's possible that others at mozilla has different
opinions, but I still think it's unlikely that this will get past our
security reviews for now.

[1] http://panopticlick.eff.org/

/ Jonas

On Thu, Jun 10, 2010 at 3:42 AM, Mike Wilson <mikewse@hotmail.com> wrote:
> 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 17:05:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:39 GMT