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

Wed May 7 21:21:46 PDT 2014

On Wed, May 7, 2014 at 7:15 PM, Steven Coul (scoul) <scoul at cisco.com> wrote:

>  Naive question(s) here.
>
>  Why does the physical number of cores ( and that is not necessarily the
> number of actionable native threads ) matter?
>

Let's say I have a task that takes 48s and I can break it in any number of
pieces.
I create 8 workers to crunch numbers. However, my system only has 6 cpus.
Total running time will be 12s (4 cpu's are idle for half the time)
If I knew there were 6, I could break it into 6 pieces -> total running
time = 8s

>  I would expect a mature system to do the best it can with hardware, in
> what the software has asked for it. Some tasks are sleepy, some are IO
> bound, some CPU - this is the job of the host kernel to cope.
>

Agreed. You can have any number of I/O-bound threads and it's up to the
kernel to manage those.

>  Whilst I can accept that there are some tasks for which you  may want to
> craft your number of workers for to get the best CPU/GPU through put - this
> sounds to be to be in the realm of something for which you probably
> shouldn’t be coding in javascript inside a web browser for.
>

Eli had good use cases in his proposal:
http://wiki.whatwg.org/wiki/NavigatorCores#Example_use_cases

>  ( I’m also not immune to concern about security re: fingerprinting - but
> then, how much information do you really get from that? Given the
> propensity to use virtual machines / cloud - the number of “processors” is
> pretty mutable ).
>
>  Personally, I like to control CPU usage - I’m happy restricting my
> browser to 2 cores - so the others are free for other tasks as a developer
> - you can’t ask an uninformed user to handle cpu binding - so relying on
> the host OS to “do the best it can” and assuming you have say 1..4 “cores”
> in an app should work.
>
>  Anything else is high-performance computing. I’m not convinced that a
> web-browser is the place to worry about that.
>
>  I’m also leary of anything not standards based - so perhaps *somebody*
> should push for a standard whereby you can ask the host os ‘ how many
> threads can you handle right now?” - which may or may not be number of
> cores - depending on system load.
>

I think we can eventually do that.
The issue is that the problem quickly spirals out of control which makes
finding a solution and coming to a consensus harder.

>  On May 7, 2014, at 7: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...
> Boris Zbarsky indicated that Firefox figures out how many workers should
> run concurrently. Maybe we can reuse that algorithm?
>
>
>>   They can already write code that overloads the system but they
>>>> currently
>>>> have *no* way of writing code that even tries to be well-behaved except
>>>> maybe to avoid workers entirely.
>>>>
>>>> I'm also a little disturbed by arguments against the general usefulness
>>>> of ncpu. We use it for the parallel JIT and parallel GC because
>>>> regardless of system load those are *the best* guesses of how many cpus
>>>> to use.
>>>>
>>>> -Fil
>>>>
>>>> On May 7, 2014, at 3:24 PM, Rik Cabanier <cabanier at gmail.com
>>>> <mailto:cabanier at gmail.com>> wrote:
>>>>
>>>>
>>>>>
>>>>>
>>>>> On Wed, May 7, 2014 at 3:19 PM, Oliver Hunt <oliver at apple.com
>>>>> <mailto:oliver at apple.com>> wrote:
>>>>>
>>>>>
>>>>>     On May 7, 2014, at 3:15 PM, Rik Cabanier <cabanier at gmail.com
>>>>>     <mailto:cabanier at gmail.com>> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>     On Wed, May 7, 2014 at 2:47 PM, Oliver Hunt <oliver at apple.com
>>>>>>     <mailto:oliver at apple.com>> wrote:
>>>>>>
>>>>>>
>>>>>>         On May 7, 2014, at 2:41 PM, Rik Cabanier <cabanier at gmail.com
>>>>>>         <mailto:cabanier at gmail.com>> wrote:
>>>>>>         >
>>>>>>         > When would I as a user, not want a page or web application
>>>>>>         to be as fast as possible? Has a user ever complained about a
>>>>>>         desktop app that uses too many of his CPU's? I think Oliver's
>>>>>>         point was that other processes might fight for the same CPU
>>>>>>         resources but that is not unexpected for users.
>>>>>>
>>>>>>         What happen if i go to your website while i'm doing something
>>>>>>         else in the background?  What if i'm playing a game while
>>>>>>         waiting for my machine to do something else? What if your
>>>>>>         page is in the background? Or my battery is running low.
>>>>>>
>>>>>>
>>>>>>     Sure. However, a page can already do this today.
>>>>>>     This will just give the author a way to make a semi-informed
>>>>>>     decision. Without this, he might just spin up too many threads
>>>>>>     and starve the rest of the system.
>>>>>>
>>>>>>         You need to stop thinking in terms of a user wanting only one
>>>>>>         thing to happen at a time.
>>>>>>
>>>>>>
>>>>>>     I'm not sure if I follow. How would this be any different from a
>>>>>>     regular desktop application?
>>>>>>
>>>>>
>>>>>     The argument is that this is not behaviour that users want - the
>>>>>     fact that desktop applications do this is a bug in the programming
>>>>>     model.
>>>>>
>>>>>     APIs like GCD were specifically created to allow a developer to
>>>>>     make an application than can automatically scale (or descale) to
>>>>>     match the behaviour that is best for the user. That’s the model we
>>>>>     want to encourage on the web.
>>>>>
>>>>>
>>>>> Filip already covered this much better than I could in the webkit bug:
>>>>> https://bugs.webkit.org/show_bug.cgi?id=132588
>>>>>
>>>>> This proposal is not about inventing a thread/task scheduling
>>>>> mechanism; this is just a way to make an informed guess without having
>>>>> to use a polyfill,
>>>>> _______________________________________________
>>>>> webkit-dev mailing list
>>>>> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev at lists.webkit.org
>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>>
>>>>
>>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>
>  _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20140507/0197b9c0/attachment.html>