[webkit-dev] support for navigator.cores or navigator.hardwareConcurrency
Ryosuke Niwa
rniwa at webkit.org
Wed May 7 16:36:36 PDT 2014
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, I'm not certain the
number of installed cores is a good metrics for that.
- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20140507/ebaae03b/attachment.html>
More information about the webkit-dev
mailing list