[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