<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 7, 2014 at 5:07 PM, Benjamin Poulain <span dir="ltr"><<a href="mailto:benjamin@webkit.org" target="_blank">benjamin@webkit.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 5/7/14, 4:13 PM, Benjamin Poulain wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 5/7/14, 3:52 PM, Filip Pizlo wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Exactly. Ben, Oliver, and others have made arguments against web<br>
workers. Rik is not proposing web workers. We already support them. The<br>
point is to give API to let developers opt into behaving nicely if they<br>
are already using web workers.<br>
</blockquote>
<br>
I have nothing against Web Workers. They are useful to dispatch<br>
background tasks.<br>
<br>
They are basically the Web equivalent dispatch_async() of GCD, which is<br>
already a very useful tool.<br>
<br>
What you are suggesting is useful for making Web Workers the tool to do<br>
high performance multi-thread computation.<br>
I don't think Web Workers are a great tool for that job at the moment. I<br>
would prefer something along TBB, GCD or something like that.<br>
<br>
<br>
For high performance computation, I think a more useful API would be<br>
something like TBB parallel_for with automatic chunking.<br>
It is actually had to do faster than that with the number of cores<br>
unless you know your task very very well.<br>
<br>
It would be a little more work for us, but a huge convenience for the<br>
users of Web Workers.<br>
</blockquote>
<br></div>
After chatting with Filip, it seems such a model is unlikely to happen anytime soon for JavaScript.<br>
<br>
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.</blockquote><div><br></div><div>Do we know what this number would be? My guess would be the number of cores for "regular" systems...</div>
<div>Boris Zbarsky indicated that Firefox figures out how many workers should run concurrently. Maybe we can reuse that algorithm?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
They can already write code that overloads the system but they currently<br>
have *no* way of writing code that even tries to be well-behaved except<br>
maybe to avoid workers entirely.<br>
<br>
I'm also a little disturbed by arguments against the general usefulness<br>
of ncpu. We use it for the parallel JIT and parallel GC because<br>
regardless of system load those are *the best* guesses of how many cpus<br>
to use.<br>
<br>
-Fil<br>
<br>
On May 7, 2014, at 3:24 PM, Rik Cabanier <<a href="mailto:cabanier@gmail.com" target="_blank">cabanier@gmail.com</a><br>
<mailto:<a href="mailto:cabanier@gmail.com" target="_blank">cabanier@gmail.com</a>>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
On Wed, May 7, 2014 at 3:19 PM, Oliver Hunt <<a href="mailto:oliver@apple.com" target="_blank">oliver@apple.com</a><br>
<mailto:<a href="mailto:oliver@apple.com" target="_blank">oliver@apple.com</a>>> wrote:<br>
<br>
<br>
On May 7, 2014, at 3:15 PM, Rik Cabanier <<a href="mailto:cabanier@gmail.com" target="_blank">cabanier@gmail.com</a><br>
<mailto:<a href="mailto:cabanier@gmail.com" target="_blank">cabanier@gmail.com</a>>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
On Wed, May 7, 2014 at 2:47 PM, Oliver Hunt <<a href="mailto:oliver@apple.com" target="_blank">oliver@apple.com</a><br>
<mailto:<a href="mailto:oliver@apple.com" target="_blank">oliver@apple.com</a>>> wrote:<br>
<br>
<br>
On May 7, 2014, at 2:41 PM, Rik Cabanier <<a href="mailto:cabanier@gmail.com" target="_blank">cabanier@gmail.com</a><br>
<mailto:<a href="mailto:cabanier@gmail.com" target="_blank">cabanier@gmail.com</a>>> wrote:<br>
><br>
> When would I as a user, not want a page or web application<br>
to be as fast as possible? Has a user ever complained about a<br>
desktop app that uses too many of his CPU's? I think Oliver's<br>
point was that other processes might fight for the same CPU<br>
resources but that is not unexpected for users.<br>
<br>
What happen if i go to your website while i'm doing something<br>
else in the background? What if i'm playing a game while<br>
waiting for my machine to do something else? What if your<br>
page is in the background? Or my battery is running low.<br>
<br>
<br>
Sure. However, a page can already do this today.<br>
This will just give the author a way to make a semi-informed<br>
decision. Without this, he might just spin up too many threads<br>
and starve the rest of the system.<br>
<br>
You need to stop thinking in terms of a user wanting only one<br>
thing to happen at a time.<br>
<br>
<br>
I'm not sure if I follow. How would this be any different from a<br>
regular desktop application?<br>
</blockquote>
<br>
The argument is that this is not behaviour that users want - the<br>
fact that desktop applications do this is a bug in the programming<br>
model.<br>
<br>
APIs like GCD were specifically created to allow a developer to<br>
make an application than can automatically scale (or descale) to<br>
match the behaviour that is best for the user. That’s the model we<br>
want to encourage on the web.<br>
<br>
<br>
Filip already covered this much better than I could in the webkit bug:<br>
<a href="https://bugs.webkit.org/show_bug.cgi?id=132588" target="_blank">https://bugs.webkit.org/show_<u></u>bug.cgi?id=132588</a><br>
<br>
This proposal is not about inventing a thread/task scheduling<br>
mechanism; this is just a way to make an informed guess without having<br>
to use a polyfill,<br>
______________________________<u></u>_________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a> <mailto:<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.<u></u>webkit.org</a>><br>
<a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">https://lists.webkit.org/<u></u>mailman/listinfo/webkit-dev</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
<a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">https://lists.webkit.org/<u></u>mailman/listinfo/webkit-dev</a><br>
<br>
</blockquote>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
<a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">https://lists.webkit.org/<u></u>mailman/listinfo/webkit-dev</a><br>
</div></div></blockquote></div><br></div></div>