A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

Navigator HW Concurrency: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
mNo edit summary
 
(60 intermediate revisions by 6 users not shown)
Line 1: Line 1:
Proposed navigator.cores API for efficient Worker allocation in parallel applications
The proposal formerly found here has been moved [https://html.spec.whatwg.org/multipage/workers.html#navigator.hardwareconcurrency to the HTML Standard]. See the page history if you are interested in the historical context surrounding the proposal.
 
== 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>&lt;a download&gt;</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]]

Latest revision as of 16:52, 10 April 2017

The proposal formerly found here has been moved to the HTML Standard. See the page history if you are interested in the historical context surrounding the proposal.

Retrieved from "https://wiki.whatwg.org/index.php?title=Navigator_HW_Concurrency&oldid=10163"