Re: [whatwg] Proposal: navigator.cores

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.

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:11:29 UTC