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 <caban...@gmail.com
<mailto:caban...@gmail.com>> wrote:
On Wed, May 7, 2014 at 3:19 PM, Oliver Hunt <oli...@apple.com
<mailto:oli...@apple.com>> wrote:
On May 7, 2014, at 3:15 PM, Rik Cabanier <caban...@gmail.com
<mailto:caban...@gmail.com>> wrote:
On Wed, May 7, 2014 at 2:47 PM, Oliver Hunt <oli...@apple.com
<mailto:oli...@apple.com>> wrote:
On May 7, 2014, at 2:41 PM, Rik Cabanier <caban...@gmail.com
<mailto:caban...@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@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
