W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2014

Re: [whatwg] Proposal: navigator.cores

From: Joe Gregorio <jcgregorio@google.com>
Date: Tue, 6 May 2014 11:51:53 -0400
Message-ID: <CAA6qSUCEfp-mm0PP0yMFNPYnuffWoy4=m77HP5neK_pHyuh8Zg@mail.gmail.com>
To: João Eiras <joaoe@opera.com>
Cc: whatwg <whatwg@lists.whatwg.org>
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.

   --joe
Received on Tuesday, 6 May 2014 15:52:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:28 UTC