- From: Joe Gregorio <jcgregorio@google.com>
- Date: Tue, 6 May 2014 11:51:53 -0400
- 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