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
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 workers = kDefaultNumber with workers = navigator.cores || kDefaultNumber. 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
<a download>) 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, 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
navigator.cores || 4to 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 cores 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
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorCPU {
readonly attribute unsigned long cores;
};
Navigator implements NavigatorCPU;
WorkerNavigator implements NavigatorCPU;
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 workers = navigator.cores || kDefaultNumber.
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:
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 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.