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

[Benjamin Poulain]

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.

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
>