On Apr 12, 2013, at 11:07 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
> On Fri, Apr 12, 2013 at 10:44 PM, Filip Pizlo <fpi...@apple.com> wrote: > > On Apr 12, 2013, at 10:43 PM, Ryosuke Niwa <rn...@webkit.org> wrote: > >> On Fri, Apr 12, 2013 at 2:13 PM, Filip Pizlo <fpi...@apple.com> wrote: >> >> On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa <rn...@webkit.org> wrote: >> >>> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo <fpi...@apple.com> wrote: >>> >>> On Apr 12, 2013, at 1:39 PM, Jarred Nicholls <jarred.nicho...@gmail.com> >>> wrote: >>> >>>> On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo <fpi...@apple.com> wrote: >>>> >>>> For as little worth as it is, I agree with you Filip that providing >>>> low-level primitives would be best in terms of a foundation for many >>>> parallel programming models. In terms of actually supporting shared >>>> mutable memory and locks, it would be a challenge for the engines to >>>> become thread-safe (internally) across contexts that share memory cells. >>>> I'd envision the sharing of mutable memory being an opt-in semantic, >>>> marking a piece of memory as being shared/mutable from multiple contexts. >>> >>> Fixing the engines is a matter of typing. ;-) >>> >>> I don't think we need to add language features for opt-in, though this is >>> an intriguing idea. >>> >>> Without opt-in, the one biggish challenge would be DOM accesses from >>> threads other than the main thread; I suspect for those the initial >>> implementation would have to throw an exception from non-main-threads if >>> you try to access a DOM node. This is akin to what some UI toolkits do: >>> they let you have threads but prohibit access UI things from anything but >>> the thread on which the runloop sits. Of course, they don't do the >>> thread-check; we would have to do it to preserve integrity and security. >>> >>> We already have Web workers for this kind of stuff, no? Is your proposal >>> significantly different from what Web worker offers? >> >> Web workers don't have shared memory. They instead have a really expensive >> message passing model. >> >> I never thought Web workers was tied to a message passing model but you've >> convinced me of this point in our earlier in-person discussion. >>> This is just a thought but is it possible to infer semantics of what Web >>> workers and use GPU or SIMD instructions instead of starting a new thread >>> as appropriate? >> >> Probably that would be hard, because the Web Worker semantics are so >> bizarre: they require copying things all over the place. It's probably an >> even worse match for SIMD/GPU/multicore than just Array.prototype.forEach(). >> >> Yeah, I was thinking that this is possible once we've added a shared memory >> model. You've also convinced me in the same in-person discussion and in a >> reply to Maciej's response that memory corruption isn't an issue in JS. I'm >> totally with you and Zoltan that the current message passing model makes Web >> workers pretty much useless. >> >> Perhaps we can come up with some JS API for shared memory & lock and propose >> it in TC39 or WebApps WG? > > I think that would be wonderful. Anyone else interested? > > Do you think it's possible to come up with an API/semantics that would allow > us to seamlessly switch between single-threaded, SIMD/GPU accelerated, and > GPU accelerations? Or would be too cumbersome / too hard to implement? That's hard. > > It would be really neat if we could dynamically detect cases where we can use > lightweight alternatives such as OpenCL instead of creating a real thread. To their credit, ParallelArrays try to do this, but do so at the cost of other constraints. Right now the web doesn't have a general concurrency mechanism. I think we should start simple. Just having the ability to use threads would be a huge improvement over what is available now! > > - R. Niwa > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
