WHATWG Wiki - User contributions [en]

User:Eligrey

2015-12-19T07:37:49Z

Eligrey: Added userpage

[http://eligrey.com Eli Grey]

Navigator HW Concurrency

2014-07-25T16:20:40Z

Eligrey: /* API */

navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications - v1.0

== 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]]

Navigator HW Concurrency

2014-05-27T19:52:51Z

Eligrey: /* Example use cases */

navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications - v1.0

== 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]]

Navigator HW Concurrency

2014-05-13T05:34:49Z

Eligrey: /* Privacy considerations */

navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications - v1.0

== 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

== 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]]

Navigator HW Concurrency

2014-05-13T03:32:17Z

Eligrey: Origin limit stuff

navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications - v1.0

== 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

== 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.

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]]

Navigator HW Concurrency

2014-05-13T03:23:44Z

Eligrey: /* API */

navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications - v1.0

== Abstract ==

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.

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

== 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

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.

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]]

Navigator HW Concurrency

2014-05-13T03:15:28Z

Eligrey: /* Abstract */

navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications - v1.0

== Abstract ==

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.

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

== 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

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.

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]]

Navigator HW Concurrency

2014-05-12T19:04:17Z

Eligrey:

navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications - v1.0

== Abstract ==

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

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

== 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

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.

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]]

Navigator HW Concurrency

2014-05-11T20:03:14Z

Eligrey: /* Privacy considerations */

Proposed navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications - v1.0

== Abstract ==

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

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

== 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

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.

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]]

Navigator HW Concurrency

2014-05-11T19:54:00Z

Eligrey:

Proposed navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications - v1.0

== Abstract ==

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

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

== 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

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 cores to reduce the efficacy of fingerprinting.

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]]

Navigator HW Concurrency

2014-05-11T19:53:41Z

Eligrey: put version on first line

Proposed navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications v1.0

== Abstract ==

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

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

== 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

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 cores to reduce the efficacy of fingerprinting.

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]]

Navigator HW Concurrency

2014-05-11T16:39:41Z

Eligrey: spec version 1.0

Proposed navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications

Editor: [http://eligrey.com Eli Grey]

Version 1.0

== Abstract ==

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

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

== 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

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 cores to reduce the efficacy of fingerprinting.

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]]

Navigator HW Concurrency

2014-05-09T17:49:38Z

Eligrey: /* Appendix */

Proposed navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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

== 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

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 cores to reduce the efficacy of fingerprinting.

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]]

Navigator HW Concurrency

2014-05-09T15:22:47Z

Eligrey: /* API */

Proposed navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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

== 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

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 cores to reduce the efficacy of fingerprinting.

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 analysis 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]]

Navigator HW Concurrency

2014-05-09T15:21:56Z

Eligrey: /* Privacy considerations */

Proposed navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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

== 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.ncpu

The number must be >= 0.

'''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 cores to reduce the efficacy of fingerprinting.

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 analysis 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]]

Navigator HW Concurrency

2014-05-09T15:12:20Z

Eligrey: /* Privacy considerations */

Proposed navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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

== 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.ncpu

The number must be >= 0.

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

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

== Privacy considerations ==

User agents MAY report an incorrect number for privacy reasons such as reducing fingerprintability. A suggested useful number for this purpose is 0, as this enables fallback support as shown above with <code>workers = navigator.hardwareConcurrency || #</code>. Alternatively, the user agent MAY report fewer than the number of actual logical cores to reduce the efficacy of fingerprinting.

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 analysis 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]]

Navigator HW Concurrency

2014-05-09T15:08:17Z

Eligrey: /* Example use cases */

Proposed navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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

== 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.ncpu

The number must be >= 0.

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

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

== Privacy considerations ==

User agents MAY report an incorrect number for privacy reasons such as reducing fingerprintability. A suggested useful incorrect number is 0, as this enables fallback support as shown above with <code>workers = navigator.hardwareConcurrency || #</code>. Alternatively, the user agent MAY report fewer that number of actual logical cores to reduce the efficacy of fingerprinting.

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 analysis 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]]

Navigator HW Concurrency

2014-05-09T04:54:35Z

Eligrey: /* Privacy considerations */

Proposed navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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.cores || 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

== 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.ncpu

The number must be >= 0.

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

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

== Privacy considerations ==

User agents MAY report an incorrect number for privacy reasons such as reducing fingerprintability. A suggested useful incorrect number is 0, as this enables fallback support as shown above with <code>workers = navigator.hardwareConcurrency || #</code>. Alternatively, the user agent MAY report fewer that number of actual logical cores to reduce the efficacy of fingerprinting.

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 analysis 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]]

Navigator HW Concurrency

2014-05-08T23:53:57Z

Eligrey: /* Abstract */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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.cores || #</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.cores || 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 0.

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

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

== Privacy considerations ==

User agents may report an incorrect number for privacy reasons such as reducing fingerprintability. A suggested useful incorrect number is 0, as this enables fallback support as shown above with <code>workers = navigator.cores || #</code>.

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 analysis 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]]

Navigator HW Concurrency

2014-05-08T19:37:30Z

Eligrey: /* Example use cases */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>workers = #</code> with <code>workers = navigator.cores || #</code> in order to split up parallel tasks between every logical core and have the OS or UA scheduler handle balancing the load. This allows transparent fallback in browsers that don't implement this feature.

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.cores || 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 0.

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

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

== Privacy considerations ==

User agents may report an incorrect number for privacy reasons such as reducing fingerprintability. A suggested useful incorrect number is 0, as this enables fallback support as shown above with <code>workers = navigator.cores || #</code>.

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 analysis 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]]

Navigator HW Concurrency

2014-05-08T19:35:27Z

Eligrey:

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>workers = #</code> with <code>workers = navigator.cores || #</code> in order to split up parallel tasks between every logical core and have the OS or UA scheduler handle balancing the load. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* 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.

* Using LZMA2 in JavaScript with as many cores as possible to compress data before saving to disk (with <code><a download></code>) faster without having to prompt 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.

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 0.

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

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

== Privacy considerations ==

User agents may report an incorrect number for privacy reasons such as reducing fingerprintability. A suggested useful incorrect number is 0, as this enables fallback support as shown above with <code>workers = navigator.cores || #</code>.

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 analysis 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]]

Navigator HW Concurrency

2014-05-08T04:50:41Z

Eligrey: /* Abstract */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>workers = kDefaultNumber</code> with <code>workers = navigator.cores || kDefaultNumber</code> in order to split up parallel tasks between every logical core and have the OS or UA scheduler handle balancing the load. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* 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.

* Using LZMA2 in JavaScript with as many cores as possible to compress data before saving to disk (with <code><a download></code>) faster without having to prompt 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.

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 0.

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

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

== Privacy considerations ==

User agents may report an incorrect number for privacy reasons such as reducing fingerprintability. A suggested useful incorrect number is 0, as this enables fallback support as shown above with <code>workers = navigator.cores || kDefaultNumber</code>.

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 analysis 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]]

Navigator HW Concurrency

2014-05-08T04:21:11Z

Eligrey: /* Abstract */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>workers = kDefaultNumber</code> with <code>workers = navigator.cores || kDefaultNumber</code> in order to split up parallel tasks between every logical core. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* 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.

* Using LZMA2 in JavaScript with as many cores as possible to compress data before saving to disk (with <code><a download></code>) faster without having to prompt 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.

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 0.

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

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

== Privacy considerations ==

User agents may report an incorrect number for privacy reasons such as reducing fingerprintability. A suggested useful incorrect number is 0, as this enables fallback support as shown above with <code>workers = navigator.cores || kDefaultNumber</code>.

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 analysis 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]]

Navigator HW Concurrency

2014-05-08T04:01:21Z

Eligrey: /* Privacy considerations */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>workers = kDefaultNumber</code> with <code>workers = navigator.cores || kDefaultNumber</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* 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.

* Using LZMA2 in JavaScript with as many cores as possible to compress data before saving to disk (with <code><a download></code>) faster without having to prompt 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.

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 0.

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

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

== Privacy considerations ==

User agents may report an incorrect number for privacy reasons such as reducing fingerprintability. A suggested useful incorrect number is 0, as this enables fallback support as shown above with <code>workers = navigator.cores || kDefaultNumber</code>.

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 analysis 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]]

Navigator HW Concurrency

2014-05-08T03:56:59Z

Eligrey: /* Privacy considerations */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>workers = kDefaultNumber</code> with <code>workers = navigator.cores || kDefaultNumber</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* 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.

* Using LZMA2 in JavaScript with as many cores as possible to compress data before saving to disk (with <code><a download></code>) faster without having to prompt 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.

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 0.

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

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

== Privacy considerations ==

User agents may report an incorrect number for privacy reasons such as reducing fingerprintability. A suggested useful incorrect number is 0, as this enables fallback support as shown above with <code>workers = navigator.cores || kDefaultNumber</code>.

System core count 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 analysis 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]]

Navigator HW Concurrency

2014-05-07T23:41:06Z

Eligrey: /* Privacy considerations */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>workers = kDefaultNumber</code> with <code>workers = navigator.cores || kDefaultNumber</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* 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.

* Using LZMA2 in JavaScript with as many cores as possible to compress data before saving to disk (with <code><a download></code>) faster without having to prompt 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.

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 0.

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

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

== Privacy considerations ==

User agents may report an incorrect number for privacy reasons. A suggested useful incorrect number is 0, as this enables fallback support as shown above with <code>workers = navigator.cores || kDefaultNumber</code>.

System core count 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 analysis 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]]

Navigator HW Concurrency

2014-05-07T23:25:42Z

Eligrey: /* Example use cases */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>workers = kDefaultNumber</code> with <code>workers = navigator.cores || kDefaultNumber</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* 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.

* Using LZMA2 in JavaScript with as many cores as possible to compress data before saving to disk (with <code><a download></code>) faster without having to prompt 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.

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 0.

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

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

== Privacy considerations ==

User agents may report an incorrect number for privacy reasons. A suggested useful incorrect number is 0, as this enables fallback support as shown above with <code>workers = navigator.cores || kDefaultNumber</code>.

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis 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]]

Navigator HW Concurrency

2014-05-07T22:22:58Z

Eligrey: /* Privacy considerations */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>workers = kDefaultNumber</code> with <code>workers = navigator.cores || kDefaultNumber</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* 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.

* Using LZMA2 in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt 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.

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 0.

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

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

== Privacy considerations ==

User agents may report an incorrect number for privacy reasons. A suggested useful incorrect number is 0, as this enables fallback support as shown above with <code>workers = navigator.cores || kDefaultNumber</code>.

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis 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]]

Navigator HW Concurrency

2014-05-07T22:08:50Z

Eligrey: /* Abstract */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>workers = kDefaultNumber</code> with <code>workers = navigator.cores || kDefaultNumber</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* 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.

* Using LZMA2 in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt 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.

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 0.

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

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

== Privacy considerations ==

User agents may report an incorrect number for privacy reasons. A suggested incorrect number is 0, as this enables fallback support as explained above with <code>workers = navigator.cores || kDefaultNumber</code>.

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis 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]]

Navigator HW Concurrency

2014-05-07T22:06:57Z

Eligrey: /* Privacy concerns */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>threads = kDefaultNumber</code> with <code>workers = navigator.cores || kDefaultNumber</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* 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.

* Using LZMA2 in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt 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.

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 0.

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

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

== Privacy considerations ==

User agents may report an incorrect number for privacy reasons. A suggested incorrect number is 0, as this enables fallback support as explained above with <code>workers = navigator.cores || kDefaultNumber</code>.

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis 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]]

Navigator HW Concurrency

2014-05-07T22:06:13Z

Eligrey: /* Abstract */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>threads = kDefaultNumber</code> with <code>workers = navigator.cores || kDefaultNumber</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* 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.

* Using LZMA2 in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt 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.

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 0.

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

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

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis 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]]

Navigator HW Concurrency

2014-05-07T21:25:35Z

Eligrey: /* API */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* 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.

* Using LZMA2 in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt 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.

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 0.

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

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

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis 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]]

Navigator HW Concurrency

2014-05-05T23:36:34Z

Eligrey: /* Example use cases */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* 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.

* Using LZMA2 in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt 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.

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 1.

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

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

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis 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]]

Navigator HW Concurrency

2014-05-05T23:24:10Z

Eligrey: /* Example use cases */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use.

* Using LZMA2 in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt 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.

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 1.

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

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

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis 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]]

Navigator HW Concurrency

2014-05-03T19:11:13Z

Eligrey: /* Appendix */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.

* Using LZMA2 in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt 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.

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 1.

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

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

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis 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]]

Navigator HW Concurrency

2014-05-03T19:00:15Z

Eligrey: /* Appendix */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.

* Using LZMA2 in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt 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.

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 1.

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

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

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis 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 WORKLOAD as you see fit.

[[Category:Proposals]]

Navigator HW Concurrency

2014-05-03T18:27:07Z

Eligrey: /* Example use cases */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.

* Using LZMA2 in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt 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.

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 1.

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

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

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis results until performance no longer increases with the number of threads.

The [https://github.com/oftn/core-estimator/blob/5337e05fc0745b10862e665ee3aa31884971bda5/core-estimator.js#L16-L18 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 WORKLOAD as you see fit.

[[Category:Proposals]]

Navigator HW Concurrency

2014-05-03T04:42:14Z

Eligrey: /* Example use cases */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.

* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt the user for their core count.

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

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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 parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 1.

'''WebIDL'''
<pre>
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorCores {
readonly attribute unsigned long cores;
};
</pre>

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis results until performance no longer increases with the number of threads.

The [https://github.com/oftn/core-estimator/blob/5337e05fc0745b10862e665ee3aa31884971bda5/core-estimator.js#L16-L18 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 WORKLOAD as you see fit.

[[Category:Proposals]]

Navigator HW Concurrency

2014-05-03T03:01:37Z

Eligrey: /* Privacy concerns */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.

* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt the user for their core count.

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

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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, they 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 parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 1.

'''WebIDL'''
<pre>
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorCores {
readonly attribute unsigned long cores;
};
</pre>

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis results until performance no longer increases with the number of threads.

The [https://github.com/oftn/core-estimator/blob/5337e05fc0745b10862e665ee3aa31884971bda5/core-estimator.js#L16-L18 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 WORKLOAD as you see fit.

[[Category:Proposals]]

Navigator HW Concurrency

2014-05-03T02:57:15Z

Eligrey: /* Abstract */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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 API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.

* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt the user for their core count.

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

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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, they 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 parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 1.

'''WebIDL'''
<pre>
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorCores {
readonly attribute unsigned long cores;
};
</pre>

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis results until performance no longer increases with the number of threads.

The [https://github.com/oftn/core-estimator/blob/5337e05fc0745b10862e665ee3aa31884971bda5/core-estimator.js#L16-L18 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 WORKLOAD as you see fit.

[[Category:Proposals]]

Navigator HW Concurrency

2014-05-03T02:48:38Z

Eligrey: /* Abstract */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

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

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

Developers can easily take advantage of this API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.

* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt the user for their core count.

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

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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, they 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 parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 1.

'''WebIDL'''
<pre>
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorCores {
readonly attribute unsigned long cores;
};
</pre>

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis results until performance no longer increases with the number of threads.

The [https://github.com/oftn/core-estimator/blob/5337e05fc0745b10862e665ee3aa31884971bda5/core-estimator.js#L16-L18 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 WORKLOAD as you see fit.

[[Category:Proposals]]

Navigator HW Concurrency

2014-05-03T02:18:35Z

Eligrey: /* Appendix */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

This specification defines an API for reading the system's total number of user-accessible logical processors.

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

Developers can easily take advantage of this API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.

* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt the user for their core count.

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

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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, they 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 parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 1.

'''WebIDL'''
<pre>
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorCores {
readonly attribute unsigned long cores;
};
</pre>

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis results until performance no longer increases with the number of threads.

The [https://github.com/oftn/core-estimator/blob/5337e05fc0745b10862e665ee3aa31884971bda5/core-estimator.js#L16-L18 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 WORKLOAD as you see fit.

[[Category:Proposals]]

Navigator HW Concurrency

2014-05-03T02:17:39Z

Eligrey: /* Appendix */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

This specification defines an API for reading the system's total number of user-accessible logical processors.

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

Developers can easily take advantage of this API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.

* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt the user for their core count.

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

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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, they 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 parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 1.

'''WebIDL'''
<pre>
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorCores {
readonly attribute unsigned long cores;
};
</pre>

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis results until performance no longer increases with the number of threads.

The [https://github.com/oftn/core-estimator/blob/5337e05fc0745b10862e665ee3aa31884971bda5/core-estimator.js#L16-L18 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 WORKLOAD.

[[Category:Proposals]]

Navigator HW Concurrency

2014-05-03T02:12:30Z

Eligrey: /* API */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

This specification defines an API for reading the system's total number of user-accessible logical processors.

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

Developers can easily take advantage of this API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.

* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt the user for their core count.

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

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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, they 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 parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers

== API ==

On getting, the <code>cores</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.ncpu

The number must be >= 1.

'''WebIDL'''
<pre>
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorCores {
readonly attribute unsigned long cores;
};
</pre>

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis results until performance no longer increases with the number of threads.

The [https://github.com/oftn/core-estimator/blob/5337e05fc0745b10862e665ee3aa31884971bda5/core-estimator.js#L16-L18 default configuration] is tuned for medium accuracy in order to finish estimation in a timely manner. If you care accuracy and precision more than runtime, add a zero or two to WORKLOAD.

[[Category:Proposals]]

Navigator HW Concurrency

2014-05-03T02:09:07Z

Eligrey: /* Appendix */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

This specification defines an API for reading the system's total number of user-accessible logical processors.

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

Developers can easily take advantage of this API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.

* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt the user for their core count.

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

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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, they 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 parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers

== API ==

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

The number must be >= 1.

'''WebIDL'''
<pre>
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorCores {
readonly attribute unsigned long cores;
};
</pre>

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis results until performance no longer increases with the number of threads.

The [https://github.com/oftn/core-estimator/blob/5337e05fc0745b10862e665ee3aa31884971bda5/core-estimator.js#L16-L18 default configuration] is tuned for medium accuracy in order to finish estimation in a timely manner. If you care accuracy and precision more than runtime, add a zero or two to WORKLOAD.

[[Category:Proposals]]

Navigator HW Concurrency

2014-05-02T23:00:19Z

Eligrey: /* API */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

This specification defines an API for reading the system's total number of user-accessible logical processors.

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

Developers can easily take advantage of this API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.

* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt the user for their core count.

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

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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, they 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 parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers

== API ==

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

The number must be >= 1.

'''WebIDL'''
<pre>
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorCores {
readonly attribute unsigned long cores;
};
</pre>

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis results until performance no longer increases with the number of threads.

[[Category:Proposals]]

Navigator HW Concurrency

2014-05-02T21:43:10Z

Eligrey: /* Example use cases */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

This specification defines an API for reading the system's total number of user-accessible logical processors.

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

Developers can easily take advantage of this API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.

* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt the user for their core count.

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

* 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.cores || 4</code> to increase performance in computers with more cores.

* 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, they 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 parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers

== API ==

On getting the <code>cores</code> property should return the number of logical cores available to the user agent. For example on OS X this should be equivalent to running sysctl -n hw.ncpu

'''WebIDL'''
<pre>
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorCores {
readonly attribute unsigned long cores;
};
</pre>

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis results until performance no longer increases with the number of threads.

[[Category:Proposals]]

Navigator HW Concurrency

2014-05-02T21:42:33Z

Eligrey: /* Example use cases */

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

This specification defines an API for reading the system's total number of user-accessible logical processors.

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

Developers can easily take advantage of this API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.

* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt the user for their core count.

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

* 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 in JavaScript suggests hardcoding the worker count to 4. All the author has to do to is replace the 4 with <code>navigator.cores || 4</code> to increase performance in computers with more cores.

* 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, they 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 parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers

== API ==

On getting the <code>cores</code> property should return the number of logical cores available to the user agent. For example on OS X this should be equivalent to running sysctl -n hw.ncpu

'''WebIDL'''
<pre>
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorCores {
readonly attribute unsigned long cores;
};
</pre>

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis results until performance no longer increases with the number of threads.

[[Category:Proposals]]

Navigator HW Concurrency

2014-05-02T21:25:22Z

Eligrey: Clean up abstract wording

Proposed navigator.cores API for smarter Worker pool allocation in parallel applications

== Abstract ==

This specification defines an API for reading the system's total number of user-accessible logical processors.

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

Developers can easily take advantage of this API by replacing code that does <code>threads = X</code> with <code>threads = navigator.cores || X</code>. This allows transparent fallback in browsers that don't implement this feature.

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 ==

* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.

* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt the user for their core count.

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

* 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 in JavaScript suggests hardcoding the worker count to 4. All the author has to do to is replace the 4 with <code>navigator.cores || 4</code> to increase performance in computers with more cores (such as their own computer).

* 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, they 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 parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers

== API ==

On getting the <code>cores</code> property should return the number of logical cores available to the user agent. For example on OS X this should be equivalent to running sysctl -n hw.ncpu

'''WebIDL'''
<pre>
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorCores {
readonly attribute unsigned long cores;
};
</pre>

== Privacy concerns ==

System core count can already be approximated with high accuracy given enough time using the polyfill in the appendix. 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 analysis results until performance no longer increases with the number of threads.

[[Category:Proposals]]

Navigator HW Concurrency

2014-05-01T20:34:15Z

Eligrey: /* Appendix */

Proposed navigator.cores API for efficient Worker allocation in parallel applications

== Abstract ==

This specification defines an API for reading the system's total number of user-accessible logical processors.

The intended use for the API is to help developers appropriately size their worker threadpools for the user's system in order to perform CPU-intensive parallel algorithms.

As opposed to previous proposals, this does not rely on creating a completely new Worker API. Instead, this API aims to help parallel applications using the current Worker API with hardcoded threadpools increase performance by changing a single line of code. All that parallel applications need to do to make use of this API is to replace code like <code>threads = X</code> with <code>threads = navigator.cores || X</code>.

Currently, highly parallel algorithms must prompt the user for how many cores they have. Many users do not know this information, nor should they be expected to know. Giving users control over thread count can lead to massive slowdowns in situations 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 when a more appropriate threadpool size is 2 or 4 threads.

== Example use cases ==

* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use. Games with optional cosmetic (not affecting gameplay) physics can also use navigator.cores to detect systems with too few cores and disable cosmetic physics by default.

* Using xz (LZMA2) in JavaScript to compress data before saving to disk (with <code><a download></code>) without having to prompt the user for their core count.

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

* 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 in JavaScript suggests hardcoding the worker count to 4. All the author has to do to is replace the 4 with <code>navigator.cores || 4</code> to increase performance in computers with more cores (such as their own computer).

* 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, they 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 parallizeable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers

== API ==

'''WebIDL'''
<pre>
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorCores {
readonly attribute unsigned long cores;
};
</pre>

== Privacy concerns ==

System core count is public information as it is already accessible with the polyfill in the appendix. If you believe core count is a privacy leak, then the only solution is to completely remove web worker threads from the specification, as a timing attack on threadpool performance will always be possible otherwise.

== Appendix ==

An 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 analysis results until performance no longer increases with the number of threads.

[[Category:Proposals]]