[webkit-dev] support for navigator.cores or navigator.hardwareConcurrency

[Ryosuke Niwa]

On Wed, May 7, 2014 at 4:37 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Wed, May 7, 2014 at 4:36 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>
>> On Mon, May 5, 2014 at 8:02 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>
>>> On Mon, May 5, 2014 at 6:23 PM, Oliver Hunt <oliver at apple.com> wrote:
>>>
>>>> On May 5, 2014, at 6:13 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>>>
>>>> Do you really want a page to know that you have a  fancy-pants 24-core
>>>>> Mac Pro rather than a little Mac mini?
>>>>>
>>>>
>>>> Yes!
>>>> If I have 24 cores ready to do work and the page can put them to use, I
>>>> would like it to do so.
>>>> At the same time, if I just have a old mac mini, I don't want the page
>>>> to launch 24 workers as that will exhaust my memory and cause contention.
>>>>
>>>>
>>>> But I don't have 24 cores available, i have 24 cores installed.  You
>>>> have no idea what the actual workload of the system is, you don't know
>>>> whether any other tabs are also using workers, you only have one piece of
>>>> information, and that is nowhere near sufficient to make a reasonable
>>>> choice.
>>>>
>>>
>>> Sure, if I have 2 tabs and each one consumes all my CPU resources,
>>> things will run at half the speed and maybe even worse because of we would
>>> use more memory.
>>>
>>
>> At most at half the speed; it could be significantly worse if each worker
>> ended up accessing completely different parts of RAM, etc...
>>
>> Furthermore, the performance characteristics of 4 physical cores with SMT
>> enabled for the total of 8 logical cores is substantially different from
>> that of a system with 4 physical cores without SMT (4 logical) or 8
>> physical cores without SMT (8 logical).  In some cases, distributing work
>> among 8 threads concurrently in such a system (4 physical cores with SMT)
>> results in a much worse performance than doing so among 4 threads.
>>
>> So while I agree that providing some API to let developers know of the
>> number of threads that could be ran concurrently
>>
>
> is useful
>
>
>> , I'm not certain the number of installed cores is a good metrics for
>> that.
>>
>
I'll throw in another point that waking up all physical cores may result in
a higher power usage compared to running the exact same task in a single
core for a longer period of time.  So we may need to take that into account
as well.

How about exposing something like the number of preferred concurrent
threads, which UA can adjust dynamically and maybe have an event that
notifies that the value has changed.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20140507/a173075a/attachment.html>