Naive question(s) here. Why does the physical number of cores ( and that is not necessarily the number of actionable native threads ) matter?
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. 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. ( 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. Steve "Harry" Coul sc...@cisco.com<mailto:sc...@cisco.com> On May 7, 2014, at 7:38 PM, Rik Cabanier <caban...@gmail.com<mailto:caban...@gmail.com>> wrote: On Wed, May 7, 2014 at 5:07 PM, Benjamin Poulain <benja...@webkit.org<mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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<mailto:webkit-dev@lists.webkit.org> https://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ 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<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
