FYI >From the WebKit side, people are leaning towards returning the logical CPU count but limit the maximum value to 8 [1]. This should cover the vast majority of systems and use cases for this property and still not expose users that are on "high value" devices..
1: https://bugs.webkit.org/show_bug.cgi?id=132588 On Tue, May 6, 2014 at 2:30 PM, Rik Cabanier <caban...@gmail.com> wrote: > > > > On Tue, May 6, 2014 at 8:51 AM, Joe Gregorio <jcgrego...@google.com>wrote: > >> On Tue, May 6, 2014 at 7:57 AM, João Eiras <jo...@opera.com> wrote: >> ... >> > >> > I guess everyone that is reading this thread understands the use cases >> well >> > and agrees with them. >> > >> > The disagreement is what kind of API you need. Many people, rightly so, >> have >> > stated that a core count gives little information that can be useful. >> > >> > It's better to have an API that determines the optimal number of >> parallel >> > tasks that can run, because who knows what else runs in a different >> process >> > (the webpage the worker is in, the browser UI, plugins, other webpages, >> > iframes, etc) with what load. Renaming 'cores' to 'parallelTaskCount' >> would >> > be a start. >> > >> >> +1 >> >> The solution proposed should actually be a solution to the problem as >> stated, which, >> from the abstract read: >> >> "The intended use for the API is to help developers make informed >> decisions regarding >> the size of their worker threadpools to perform parallel algorithms." >> >> So the solution should be some information about the maximum number of >> parallel >> workers that a page can expect to run, which may have no relation to >> the number of >> cores, physical or virtual. The browser should be allowed to determine >> what that number >> is based on all the factors it has visibility to, such as load, cores, >> and policy. >> >> Returning the number is actually important, for example, "physics >> engines for WebGL >> games", how you shard the work may depend on knowing how many parallel >> workers >> you should schedule. >> > > It seems everyone is in agreement that this API should return the number > of useful parallel tasks. > > So far, people have proposed several names: > - cores -> this seems confusing since the returned number might be lower > - concurrency -> there can be more concurrent tasks than there are logical > cores > - hardwareConcurrency > - parallelTaskCount > > Leaving the question of fingerprinting aside for now, what name would > people prefer? >
