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-requ...@w3.org [mailto:public-webapps-
requ...@w3.org] On Behalf Of bugzi...@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: i...@hixie.ch
ReportedBy: robert.enn...@intel.com
QAContact: member-webapi-...@w3.org
CC: m...@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
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 mike...@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-requ...@w3.org [mailto:public-webapps-
requ...@w3.org] On Behalf Of bugzi...@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: i...@hixie.ch
ReportedBy: robert.enn...@intel.com
QAContact: member-webapi-...@w3.org
CC: m...@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
Re: [Bug 9823] New: Add maxExecutionContexts property with number of hardware execution contexts
On Thu, Jun 10, 2010 at 10:04 AM, Jonas Sicking jo...@sicking.cc wrote: 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. While I'm very much in favour of reducing the browser fingerprint, I suspect that if you expose non-determinism via concurrent message-passing between web workers, a web app can probably work out how many cores the machine has. It can spawn multiple web workers, send many messages, and look at the message interleaving. (Do web workers have access to any high resolution timers that would make this easier?) That said, just because it's possible to get this information doesn't mean it should be made easy. Cheers, Mark
RE: [Bug 9823] New: Add maxExecutionContexts property with number of hardware execution contexts
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-requ...@w3.org [mailto:public-webapps-
requ...@w3.org] On Behalf Of bugzi...@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: i...@hixie.ch
ReportedBy: robert.enn...@intel.com
QAContact: member-webapi-...@w3.org
CC: m...@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.
