On Wed, May 7, 2014 at 7:15 PM, Steven Coul (scoul) <sc...@cisco.com> wrote:
> Naive question(s) here. > > Why does the physical number of cores ( and that is not necessarily the > number of actionable native threads ) matter? > Let's say I have a task that takes 48s and I can break it in any number of pieces. 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) If I knew there were 6, I could break it into 6 pieces -> total running time = 8s > 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. > Agreed. You can have any number of I/O-bound threads and it's up to the kernel to manage those. > 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. > Eli had good use cases in his proposal: http://wiki.whatwg.org/wiki/NavigatorCores#Example_use_cases > ( 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 ). > > 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. > > Anything else is high-performance computing. I’m not convinced that a > web-browser is the place to worry about that. > > 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. > I think we can eventually do that. The issue is that the problem quickly spirals out of control which makes finding a solution and coming to a consensus harder. > On May 7, 2014, at 7: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... > Boris Zbarsky indicated that Firefox figures out how many workers should > run concurrently. Maybe we can reuse that algorithm? > > >> 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 >> > > _______________________________________________ > 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
