<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 7, 2014 at 9:32 PM, Ryosuke Niwa <span dir="ltr"><<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@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 dir="ltr"><div><div class="h5">On Wed, May 7, 2014 at 9:08 PM, Rik Cabanier <span dir="ltr"><<a href="mailto:cabanier@gmail.com" target="_blank">cabanier@gmail.com</a>></span> wrote:<br>
</div></div><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">
<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 dir="ltr"><span style="color:rgb(80,0,80)">On Wed, May 7, 2014 at 7:58 PM, Brady Eidson </span><span dir="ltr" style="color:rgb(80,0,80)"><<a href="mailto:beidson@apple.com" target="_blank">beidson@apple.com</a>></span><span style="color:rgb(80,0,80)"> wrote:</span><br>
<div class="gmail_extra"><div class="gmail_quote"><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><br><div><div>
On May 7, 2014, at 5:38 PM, Rik Cabanier <<a href="mailto:cabanier@gmail.com" target="_blank">cabanier@gmail.com</a>> wrote:</div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><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></div></div></blockquote><div><br></div></div></div></div><div>Define “regular” systems: </div></div></blockquote><div><br></div></div></div><div>"regular" systems are those were all running CPU's are of the same type. There are some exotic systems where some CPU's are much faster than others. I'm unsure what we should return there.</div>
<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> As Ryosuke mentioned, for systems that run on battery power (read: a vast majority of systems), keeping cores asleep to preserve battery life is often preferable to the user instead of waking up all available hardware and building up heat.</div>
</div></blockquote><div><br></div></div><div>Actually, spinning up more cores while on battery power might be more efficient.</div></div></div></div></blockquote><div><br></div></div></div><div>This depends on the kinds of workloads.</div>
<div class="">
<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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>I'm having a hard time finding good data, but take this chart for instance: <a href="http://www.anandtech.com/show/7903/samsung-galaxy-s-5-review/5" target="_blank">http://www.anandtech.com/show/7903/samsung-galaxy-s-5-review/5</a></div>
<div>Let's say you have a task that would take 1 core 4 seconds. This would mean 4 x 2612mw = 10456mw</div><div>Now if you can divide it over 4 cores: display = 854 (AMOLED), cpu core (simplified) = 2612 - 854 = 1758mw -> 854 + (4 x 1758mw) = 7886mw</div>
</div></div></div></blockquote><div><br></div></div><div>If your app wasn't doing anything, one of the CPU is bound to be awaken by other daemons and system kernel itself. So keeping one of the cores awake is relatively cheap. So you can't just add or subtract wattage like that.</div>
</div></div></div></blockquote><div><br></div><div>I agree; this was just a simplified example. I can't find precise data on how much a power a CPU uses.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>On the desktop world, Intel Turbo boost [1] boosts single thread performance but at the expense of making the CPU run much hotter.</div></div></div></div></blockquote><div><br></div></div><div>Precisely because of this technology, doing all the work in a single thread might be faster in some cases.</div>
</div></div></div></blockquote><div><br></div><div>I just brought this up to highlight that running a single thread might use more power than breaking it up.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>Putting an even load will reduce power usage so the ratio of operator/watt will improve There's a paper from NVidia that also describes this [2].</div><div><br></div><div>Just because you can break up the work, doesn't mean that you do MORE work.</div>
<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>Also, what type of cores? Physical cores, or logical cores?</div>
</div></div></blockquote><div><br></div></div><div>It would be logical cores. I think we're all compiling and running WebKit with hyper-threading turned on so it seems to work fine for parallel processing these days.</div>
</div></div></div></blockquote><div><br></div></div><div>That's because compiling C code happens to fall within a set of workloads that could benefit from running concurrently with SMT/HyperThreading.</div><div><br></div>
<div>
OS X's scheduler, for example, appears to have been very carefully tuned not to schedule two high priority jobs to two logical cores on a single physical core when there are more physical cores available.</div></div>
</div></div></blockquote><div><br></div><div>Interesting! </div></div></div></div>