rniwa at webkit.org
Fri Apr 12 23:07:03 PDT 2013
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>
>>> 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
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
- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev