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

[Rik Cabanier]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20140507/ef4596f1/attachment.html>