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?