[webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

[Filip Pizlo]

On Apr 12, 2013, at 11:07 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Fri, Apr 12, 2013 at 10:44 PM, Filip Pizlo <fpizlo at apple.com> wrote:
> 
> On Apr 12, 2013, at 10:43 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> 
>> On Fri, Apr 12, 2013 at 2:13 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>> 
>> On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>> 
>>> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>>> 
>>> On Apr 12, 2013, at 1:39 PM, Jarred Nicholls <jarred.nicholls at gmail.com> wrote:
>>> 
>>>> On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo <fpizlo at 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
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130412/57cebc40/attachment.html>