Re: [whatwg] Proposal: navigator.cores

On Mon, May 5, 2014 at 11:10 AM, David Young <dyoung@pobox.com> wrote:

> On Sat, May 03, 2014 at 10:49:00AM -0700, Adam Barth wrote:
> > Over on blink-dev, we've been discussing [1] adding a property to
> navigator
> > that reports the number of cores [2].  As far as I can tell, this
> > functionality exists in every other platform (including iOS and Android).
> >  Some of the use cases for this feature have been discussed previously on
> > this mailing list [3] and rejected in favor of a more complex system,
> > perhaps similar to Grand Central Dispatch [4].  Others have raised
> concerns
> > that exposing the number of cores could lead to increased fidelity of
> > fingerprinting [5].
>
> navigator.cores seems to invite developers to try to write web apps
> that make local decisions about the scheduling of work on cores when
> they're missing important essential knowledge about the global context:
> cores may not be equally fast, energy-efficient, or available;


Eli already pointed out that this is not a problem. Heterogeneous systems
still allow concurrency on the different cores; the faster ones will simply
finish their work faster


> global
> scheduling decisions may be more sophisticated than, or in opposition to
> your local scheduling decisions.
>
> I think that "a more complex system," such as Grand Central Dispatch, is
> probably more effective and less complicated than each web app trying
> independently, without any real information, to optimize its use of
> cores.
>

We are now 6 years from that proposal and nothing has happened since. (Is
there any data on how successful Grand Central is?)
This is not an optimal solution but at least it gives authors a way to make
a semi-informed decision. If this is not provided, they will either make a
poor guess or just optimize for the most popular platform.

As previous pointed out, a thread scheduling solution will need the optimal
number of concurrent tasks too.

Received on Monday, 5 May 2014 20:05:59 UTC