Navigator HW Concurrency - Revision history

Domenic at 16:52, 10 April 2017

2017-04-10T16:52:34Z

← Older revision		Revision as of 16:52, 10 April 2017
Line 1:		Line 1:
	The proposal formerly found here has been moved [~~to the HTML Standard](~~https://html.spec.whatwg.org/multipage/workers.html#navigator.hardwareconcurrency). See the page history if you are interested in the historical context surrounding the proposal.		The proposal formerly found here has been moved [https://html.spec.whatwg.org/multipage/workers.html#navigator.hardwareconcurrency to the HTML Standard]. See the page history if you are interested in the historical context surrounding the proposal.

Domenic: Replaced content with "The proposal formerly found here has been moved [to the HTML Standard](https://html.spec.whatwg.org/multipage/workers.html#navigator.hardwareconcurrency). See the page his..."

2017-04-10T16:52:04Z

Replaced content with "The proposal formerly found here has been moved [to the HTML Standard](https://html.spec.whatwg.org/multipage/workers.html#navigator.hardwareconcurrency). See the page his..."

← Older revision		Revision as of 16:52, 10 April 2017
Line 1:		Line 1:
	~~navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications - v1.0~~		The proposal formerly found here has been moved [to the HTML Standard](https://html.spec.whatwg.org/multipage/workers.html#navigator.hardwareconcurrency). See the page history if you are interested in the historical context surrounding the proposal.

	~~== Abstract ==~~

	~~This specification defines an API for reading the system's total number of logical processors available to the user agent, up to an optional thread limit per origin.~~

	The ~~intended use for the API is~~ to ~~help developers make informed decisions regarding~~ the ~~size of their worker threadpools to perform parallel algorithms.~~

	Developers can easily take advantage of this in existing parallel applications implemented with web workers by replacing code that does <code>workers = #</code> with <code>workers = navigator.hardwareConcurrency \|\| #</code> in order to split up parallel tasks between every logical core. The OS or UA scheduler will handle balancing the load of these threads with everything else on the system.

	Currently, highly parallel algorithms must prompt the user for how many cores they have, but many users don't know this information or understand where to get it. Giving users control over thread count can also cause issues where the user thinks the highest option is best. For example, this can result in 32 threads being run on a user's dual core laptop.

	~~== Example use cases ==~~

	* Image processing in online photo editors is highly parallelizable but often hardcoded to a specific worker count. For example, [http://www.sitepoint.com/using-web-workers-to-improve-image-manipulation-performance/ this recent blog post] on image processing with worker threads in JavaScript suggests hardcoding the worker count to 4. All the author has to do to is replace the 4 with <code>navigator.hardwareConcurrency \|\| 4</code> to increase performance in computers with more cores.

	* Using LZMA2 in JavaScript with as many cores as possible to compress data faster without having to prompt the user for their core count.

	* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use without prompting the user for their core count.

	* Running realtime object/face/movement/etc. detection algorithms efficiently on webcam input or video file input, without prompting the user for their core count.

	* Multithreaded silent OCR: A current attempt at automatic silent OCR is http://projectnaptha.com/ (single-threaded). If Project Naptha is ever going to use the multithreaded Ocrad mode to increase performance, it must currently prompt the user for a core count. This defeats the purpose of a silent background processing script by interrupting the user with a prompt.

	* Anything else highly parallelizable, such as raytracer webapps like http://~~tech~~.~~pusherhq~~.~~com/demo/raytracer_workers and http://nerget~~.~~com~~/~~rayjs-mt~~/~~rayjs~~.html

	~~== API ==~~

	~~On getting, the <code>hardwareConcurrency</code> property should return the number of logical processors available to the user agent, up to an optional thread limit per origin~~. ~~For example on OS X this should be equivalent to running sysctl -n hw.availcpu~~

	~~The number must be ≥ 1.~~

	~~'''WebIDL'''~~
	~~<pre>~~
	~~[NoInterfaceObject, Exposed=(Window,Worker~~)]
	~~interface NavigatorCPU {~~
	~~readonly attribute unsigned long hardwareConcurrency;~~
	};

	~~Navigator implements NavigatorCPU;~~
	~~WorkerNavigator implements NavigatorCPU;~~
	~~</pre>~~

	~~== Privacy considerations ==~~

	~~The user agent MAY report fewer than the number of actual logical processors to reduce the efficacy of fingerprinting~~. ~~Firefox already implements a limit of 20 concurrent workers per origin.~~

	~~The total number of cores available to~~ the ~~user agent can already be approximated with high accuracy given enough time using the polyfill in the appendix on a system with low to moderate system load. Chrome also exposes it through PNaCl.~~

	~~== Appendix ==~~

	~~An open source O(log n) (in the number of cores) polyfill~~ in ~~JavaScript can be found at:~~

	~~:https://github.com/oftn/core-estimator~~

	~~The polyfill works by running a timing attack on~~ the ~~measured runtime of a worker threadpool that is resized according to a binary search and statistical results until performance no longer increases with~~ the ~~number of threads~~.

	The [https://github.com/oftn/core-estimator/blob/cc56e924e450554d4f4c7e1d42e53a42a7633bb2/core-estimator.js#L16-L20 default configuration] is tuned for medium accuracy in order to finish the estimation in a timely manner. If you care about accuracy more than runtime length, increase the workload as you see fit.

	~~[[Category:Proposals]]~~

Philipj: /* API */ WebIDL syntax

2015-06-10T21:42:32Z

API: WebIDL syntax

← Older revision		Revision as of 21:42, 10 June 2015
Line 33:		Line 33:
	'''WebIDL'''		'''WebIDL'''
	<pre>		<pre>
	[NoInterfaceObject, Exposed=Window,Worker]		[NoInterfaceObject, Exposed=(Window,Worker)]
	interface NavigatorCPU {		interface NavigatorCPU {
	readonly attribute unsigned long hardwareConcurrency;		readonly attribute unsigned long hardwareConcurrency;

Eligrey: /* API */

2014-07-25T16:20:40Z

API

← Older revision		Revision as of 16:20, 25 July 2014
Line 29:		Line 29:
	On getting, the <code>hardwareConcurrency</code> property should return the number of logical processors available to the user agent, up to an optional thread limit per origin. For example on OS X this should be equivalent to running sysctl -n hw.availcpu		On getting, the <code>hardwareConcurrency</code> property should return the number of logical processors available to the user agent, up to an optional thread limit per origin. For example on OS X this should be equivalent to running sysctl -n hw.availcpu

	The number must be >= 1.		The number must be ≥ 1.

	'''WebIDL'''		'''WebIDL'''

Eligrey: /* Example use cases */

2014-05-27T19:52:51Z

Example use cases

← Older revision		Revision as of 19:52, 27 May 2014
Line 23:		Line 23:
	* Multithreaded silent OCR: A current attempt at automatic silent OCR is http://projectnaptha.com/ (single-threaded). If Project Naptha is ever going to use the multithreaded Ocrad mode to increase performance, it must currently prompt the user for a core count. This defeats the purpose of a silent background processing script by interrupting the user with a prompt.		* Multithreaded silent OCR: A current attempt at automatic silent OCR is http://projectnaptha.com/ (single-threaded). If Project Naptha is ever going to use the multithreaded Ocrad mode to increase performance, it must currently prompt the user for a core count. This defeats the purpose of a silent background processing script by interrupting the user with a prompt.

	* Anything else highly parallelizable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers		* Anything else highly parallelizable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers and http://nerget.com/rayjs-mt/rayjs.html

	== API ==		== API ==

Eligrey: /* Privacy considerations */

2014-05-13T05:34:49Z

Privacy considerations

← Older revision		Revision as of 05:34, 13 May 2014
Line 44:		Line 44:
	== Privacy considerations ==		== Privacy considerations ==

	The user agent MAY report fewer than the number of actual logical processors to reduce the efficacy of fingerprinting. Firefox already implements a limit of 20 concurrent workers.		The user agent MAY report fewer than the number of actual logical processors to reduce the efficacy of fingerprinting. Firefox already implements a limit of 20 concurrent workers per origin.

	The total number of cores available to the user agent can already be approximated with high accuracy given enough time using the polyfill in the appendix on a system with low to moderate system load. Chrome also exposes it through PNaCl.		The total number of cores available to the user agent can already be approximated with high accuracy given enough time using the polyfill in the appendix on a system with low to moderate system load. Chrome also exposes it through PNaCl.

Eligrey: Origin limit stuff

2014-05-13T03:32:17Z

Origin limit stuff

← Older revision		Revision as of 03:32, 13 May 2014
Line 3:		Line 3:
	== Abstract ==		== Abstract ==

	This specification defines an API for reading the system's total number of logical processors available to the user agent per origin.		This specification defines an API for reading the system's total number of logical processors available to the user agent, up to an optional thread limit per origin.

	The intended use for the API is to help developers make informed decisions regarding the size of their worker threadpools to perform parallel algorithms.		The intended use for the API is to help developers make informed decisions regarding the size of their worker threadpools to perform parallel algorithms.
Line 27:		Line 27:
	== API ==		== API ==

	On getting, the <code>hardwareConcurrency</code> property should return the number of logical processors available to the user agent per origin. For example on OS X this should be equivalent to running sysctl -n hw.availcpu		On getting, the <code>hardwareConcurrency</code> property should return the number of logical processors available to the user agent, up to an optional thread limit per origin. For example on OS X this should be equivalent to running sysctl -n hw.availcpu

	The number must be >= 1.		The number must be >= 1.
Line 44:		Line 44:
	== Privacy considerations ==		== Privacy considerations ==

	The user agent MAY report fewer than the number of actual logical processors to reduce the efficacy of fingerprinting.		The user agent MAY report fewer than the number of actual logical processors to reduce the efficacy of fingerprinting. Firefox already implements a limit of 20 concurrent workers.

	The total number of cores available to the user agent can already be approximated with high accuracy given enough time using the polyfill in the appendix on a system with low to moderate system load. Chrome also exposes it through PNaCl.		The total number of cores available to the user agent can already be approximated with high accuracy given enough time using the polyfill in the appendix on a system with low to moderate system load. Chrome also exposes it through PNaCl.

Eligrey: /* API */

2014-05-13T03:23:44Z

API

← Older revision		Revision as of 03:23, 13 May 2014
Line 27:		Line 27:
	== API ==		== API ==

	On getting, the <code>hardwareConcurrency</code> property should return the number of logical processors available to the user agent. For example on OS X this should be equivalent to running sysctl -n hw.availcpu		On getting, the <code>hardwareConcurrency</code> property should return the number of logical processors available to the user agent per origin. For example on OS X this should be equivalent to running sysctl -n hw.availcpu

	The number must be >= 1.		The number must be >= 1.

Eligrey: /* Abstract */

2014-05-13T03:15:28Z

Abstract

← Older revision		Revision as of 03:15, 13 May 2014
Line 3:		Line 3:
	== Abstract ==		== Abstract ==

	This specification defines an API for reading the system's total number of logical processors available to the user agent.		This specification defines an API for reading the system's total number of logical processors available to the user agent per origin.

	The intended use for the API is to help developers make informed decisions regarding the size of their worker threadpools to perform parallel algorithms.		The intended use for the API is to help developers make informed decisions regarding the size of their worker threadpools to perform parallel algorithms.

Eligrey at 19:04, 12 May 2014

2014-05-12T19:04:17Z

← Older revision		Revision as of 19:04, 12 May 2014
Line 1:		Line 1:
	~~Proposed~~ navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications - v1.0		navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications - v1.0

	== Abstract ==		== Abstract ==