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

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 UTC