<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 7, 2014 at 7:15 PM, Steven Coul (scoul) <span dir="ltr"><<a href="mailto:scoul@cisco.com" target="_blank">scoul@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
Naive question(s) here.
<div><br>
</div>
<div>Why does the physical number of cores ( and that is not necessarily the number of actionable native threads ) matter?</div></div></blockquote><div><br></div><div>Let's say I have a task that takes 48s and I can break it in any number of pieces.</div>
<div>I create 8 workers to crunch numbers. However, my system only has 6 cpus. Total running time will be 12s (4 cpu's are idle for half the time)</div><div>If I knew there were 6, I could break it into 6 pieces -> total running time = 8s</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">
<div><br>
</div>
<div>I would expect a mature system to do the best it can with hardware, in what the software has asked for it. Some tasks are sleepy, some are IO bound, some CPU - this is the job of the host kernel to cope.</div></div>
</blockquote><div><br></div><div>Agreed. You can have any number of I/O-bound threads and it's up to the kernel to manage those.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>Whilst I can accept that there are some tasks for which you may want to craft your number of workers for to get the best CPU/GPU through put - this sounds to be to be in the realm of something for which you probably shouldn’t be coding in javascript inside
a web browser for.</div></div></blockquote><div><br></div><div>Eli had good use cases in his proposal: <a href="http://wiki.whatwg.org/wiki/NavigatorCores#Example_use_cases">http://wiki.whatwg.org/wiki/NavigatorCores#Example_use_cases</a></div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>( I’m also not immune to concern about security re: fingerprinting - but then, how much information do you really get from that? Given the propensity to use virtual machines / cloud - the number of “processors” is pretty mutable ).</div>
<div><br>
</div>
<div>Personally, I like to control CPU usage - I’m happy restricting my browser to 2 cores - so the others are free for other tasks as a developer - you can’t ask an uninformed user to handle cpu binding - so relying on the host OS to “do the best it can” and
assuming you have say 1..4 “cores” in an app should work.</div>
<div><br>
</div>
<div>Anything else is high-performance computing. I’m not convinced that a web-browser is the place to worry about that.</div>
<div><br>
</div>
<div>I’m also leary of anything not standards based - so perhaps *somebody* should push for a standard whereby you can ask the host os ‘ how many threads can you handle right now?” - which may or may not be number of cores - depending on system load.</div>
</div></blockquote><div><br></div><div>I think we can eventually do that. </div><div>The issue is that the problem quickly spirals out of control which makes finding a solution and coming to a consensus harder.</div><div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>
<div>
<div>On May 7, 2014, at 7:38 PM, Rik Cabanier <<a href="mailto:cabanier@gmail.com" target="_blank">cabanier@gmail.com</a>> wrote:</div>
<br>
<blockquote type="cite">
<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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>On 5/7/14, 4:13 PM, Benjamin Poulain wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 5/7/14, 3:52 PM, Filip Pizlo wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________<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/mailman/listinfo/webkit-dev</a><br>
</blockquote>
</div>
<br>
</div></div></div>
</div>
</blockquote></div><br></div></div>