On Wed, May 7, 2014 at 9:32 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
> On Wed, May 7, 2014 at 9:08 PM, Rik Cabanier <caban...@gmail.com> wrote: > >> On Wed, May 7, 2014 at 7:58 PM, Brady Eidson <beid...@apple.com> wrote: >> >>> >>> On May 7, 2014, at 5:38 PM, Rik Cabanier <caban...@gmail.com> wrote: >>> >>> On Wed, May 7, 2014 at 5:07 PM, Benjamin Poulain <benja...@webkit.org>wrote: >>> >>>> 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. >>> >>> >>> Do we know what this number would be? My guess would be the number of >>> cores for "regular" systems... >>> >>> >>> Define “regular” systems: >>> >> >> "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. >> >> >>> 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. >>> >> >> Actually, spinning up more cores while on battery power might be more >> efficient. >> > > This depends on the kinds of workloads. > > I'm having a hard time finding good data, but take this chart for >> instance: http://www.anandtech.com/show/7903/samsung-galaxy-s-5-review/5 >> Let's say you have a task that would take 1 core 4 seconds. This would >> mean 4 x 2612mw = 10456mw >> Now if you can divide it over 4 cores: display = 854 (AMOLED), cpu core >> (simplified) = 2612 - 854 = 1758mw -> 854 + (4 x 1758mw) = 7886mw >> > > 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. > I agree; this was just a simplified example. I can't find precise data on how much a power a CPU uses. > On the desktop world, Intel Turbo boost [1] boosts single thread >> performance but at the expense of making the CPU run much hotter. >> > > Precisely because of this technology, doing all the work in a single > thread might be faster in some cases. > I just brought this up to highlight that running a single thread might use more power than breaking it up. > 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]. >> >> Just because you can break up the work, doesn't mean that you do MORE >> work. >> >> >>> Also, what type of cores? Physical cores, or logical cores? >>> >> >> 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. >> > > That's because compiling C code happens to fall within a set of workloads > that could benefit from running concurrently with SMT/HyperThreading. > > 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. > Interesting!
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
