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

[Brady Eidson]

On May 7, 2014, at 9:08 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> 
> 
> 
> On Wed, May 7, 2014 at 7:58 PM, Brady Eidson <beidson at apple.com> wrote:
> 
> On May 7, 2014, at 5:38 PM, Rik Cabanier <cabanier at gmail.com> wrote:
> 
>> 
>> 
>> 
>> On Wed, May 7, 2014 at 5:07 PM, Benjamin Poulain <benjamin at webkit.org> wrote:
>> On 5/7/14, 4:13 PM, Benjamin Poulain wrote:
>> On 5/7/14, 3:52 PM, Filip Pizlo wrote:
>> Exactly. Ben, Oliver, and others have made arguments against web
>> workers. Rik is not proposing web workers.  We already support them. The
>> point is to give API to let developers opt into behaving nicely if they
>> are already using web workers.
>> 
>> I have nothing against Web Workers. They are useful to dispatch
>> background tasks.
>> 
>> They are basically the Web equivalent dispatch_async() of GCD, which is
>> already a very useful tool.
>> 
>> What you are suggesting is useful for making Web Workers the tool to do
>> high performance multi-thread computation.
>> I don't think Web Workers are a great tool for that job at the moment. I
>> would prefer something along TBB, GCD or something like that.
>> 
>> 
>> For high performance computation, I think a more useful API would be
>> something like TBB parallel_for with automatic chunking.
>> It is actually had to do faster than that with the number of cores
>> unless you know your task very very well.
>> 
>> It would be a little more work for us, but a huge convenience for the
>> users of Web Workers.
>> 
>> After chatting with Filip, it seems such a model is unlikely to happen anytime soon for JavaScript.
>> 
>> In the absence of any tasks/kernels model, I am in favor of exposing a "good number of thread" API. It is definitely better than nothing.
>> 
>> Do we know what this number would be? My guess would be the number of cores for "regular" systems...
> 
> Define “regular” systems:
> 
> "regular" systems are those were all running CPU's are of the same type. There are some exotic systems where some CPU's are much faster than others. I'm unsure what we should return there.
>  
>  As Ryosuke mentioned, for systems that run on battery power (read: a vast majority of systems), keeping cores asleep to preserve battery life is often preferable to the user instead of waking up all available hardware and building up heat.
> 
> Actually, spinning up more cores while on battery power might be more efficient.

> 
> I'm having a hard time finding good data, but take this chart for instance: http://www.anandtech.com/show/7903/samsung-galaxy-s-5-review/5
> Let's say you have a task that would take 1 core 4 seconds. This would mean 4 x 2612mw = 10456mw
> Now if you can divide it over 4 cores: display = 854 (AMOLED), cpu core (simplified) = 2612 - 854 = 1758mw -> 854 + (4 x 1758mw) = 7886mw
> 
> On the desktop world, Intel Turbo boost [1] boosts single thread performance but at the expense of making the CPU run much hotter. Putting an even load will reduce power usage so the ratio of operator/watt will improve
> There's a paper from NVidia that also describes this [2].
> 
> Just because you can break up the work, doesn't mean that you do MORE work.

I’m not arguing that more cores over less time can never be more efficient.  Sure it can be, on certain systems and under certain conditions.

But less cores over more time can also be more efficient in other circumstances.  Waking cores can be expensive, both from a battery and time perspective.  In fact transitioning through P-states, T-states, and C-states all incur a cost.

A lot of this discussion has been focused on “make long running computational algorithms better”, meaning the types of threads that last minutes or even hours.  Much more common are the many threads that transition in and out of existence over short periods of time, where attempting to minimize these transitions is important for battery life.

> Maybe we can keep the current patch that returns the number of available CPU's for now. [3]

This conversation has devolved into talking about the cost/benefit analysis of using all the cores versus taking it easy on the system, but it has completely ignored the fingerprinting problem.

Instead of passive/aggressively commenting on the patch, I’ve now actually r-‘ed it until at least that concern is resolved.

~Brady

> 
> 1: http://www.intel.com/content/www/us/en/architecture-and-technology/turbo-boost/turbo-boost-technology.html?wapkw=turbo+boost
> 2: page 12 of http://www.nvidia.com/content/PDF/tegra_white_papers/tegra-whitepaper-0911b.pdf
> 3: https://bugs.webkit.org/show_bug.cgi?id=132588
> 

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