[webkit-dev] support for navigator.cores or navigator.hardwareConcurrency
benjamin at webkit.org
Wed May 7 16:13:14 PDT 2014
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
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.
> 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.
> 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
>> 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:
>> 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>
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev