Re: [whatwg] Proposal: navigator.cores

On Thu, May 8, 2014 at 7:07 PM, Joe Gregorio <jcgregorio@google.com> wrote:

> Maybe we can also return their RAM, but limit it to a maximum of 640K,
> since no one will need more than that :-)
>
> I think in a few years the limit to 8 cores will look just as silly.


Once 16 is common, WebKit will be updated to 16.
Maybe by then we'll also have a task scheduling framework to go along.


>  On Thu, May 8, 2014 at 10:02 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> > 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 <cabanier@gmail.com> wrote:
> >>
> >>
> >>
> >>
> >> On Tue, May 6, 2014 at 8:51 AM, Joe Gregorio <jcgregorio@google.com>
> >> wrote:
> >>>
> >>> On Tue, May 6, 2014 at 7:57 AM, João Eiras <joaoe@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?
> >
> >
>

Received on Friday, 9 May 2014 02:24:55 UTC