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

[Benjamin Poulain]

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.

Benjamin

>> 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
>>
>