Re: [whatwg] Proposal: navigator.cores

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:04:39 UTC