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
- hardwareConcurrency
- parallelTaskCount

Leaving the question of fingerprinting aside for now, what name would
people prefer?

Reply via email to