On Mon, Sep 24, 2012 at 9:17 AM, Jussi Kalliokoski < [email protected]> wrote:
> As I suspected. Glad to hear my assumptions were correct. :) I think this > is a good thing actually, we'll have a good "excuse" not to have shared > state in the language (fp yay). > > For the record, I've updated my initial JS fragment shading experiment > using Workers (on which my previous example was based) to take use of the > Transferrables [1] [2]. If you compare the results on Chrome and Firefox, > the benefit of Transferrables is quite impressive. > > There seems to be a small downside to Transferrables though, as I couldn't > figure out a way to send parts of an ArrayBuffer using them. > > Cheers, > Jussi > > [1] http://labs.avd.io/parallel-shading/test.html > Made laptop too hot for lap ;). > [2] https://gist.github.com/2689799 > > > On Mon, Sep 24, 2012 at 5:59 PM, Alex Russell <[email protected]>wrote: > >> Let me put bounds on this, then: >> >> Approaches that enable shared mutable state are non-starters. A "send" >> based-approach might work (e.g., Worker Tranferrables) as might automatic >> parallelization (e.g., RiverTrail) -- but threads and thread-like semantics >> aren't gonna happen. Turn-based execution with an event loop is how JS >> works and anything that changes that apparent semantic won't fly. >> >> Regards >> >> On Mon, Sep 24, 2012 at 3:09 PM, Jussi Kalliokoski < >> [email protected]> wrote: >> >>> Hi Rick! >>> >>> Thanks for the links, very interesting! I was already aware of River >>> Trail and other concurrency proposals for JavaScript, my purpose for this >>> thread was anyway to get good clarification on what approaches are >>> impossible and why and what approaches are possible and what are their >>> virtues / downsides. So thanks again, those two papers are more than I >>> hoped for! But I hope that there will be more discussion about this. >>> >>> Cheers, >>> Jussi >>> >>> >>> On Mon, Sep 24, 2012 at 4:55 PM, Hudson, Rick <[email protected]>wrote: >>> >>>> Besides web workers there are two straw man proposals that address >>>> adding parallelism and concurrency to JavaScript.**** >>>> >>>> ** ** >>>> >>>> http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism and >>>> http://wiki.ecmascript.org/doku.php?id=strawman:concurrency.**** >>>> >>>> ** ** >>>> >>>> The Parallel JavaScript (River Trail) proposal has a prototype >>>> implementation available at >>>> https://github.com/rivertrail/rivertrail/wiki. You should be able to >>>> implement your example’s functionality using this API.**** >>>> >>>> ** ** >>>> >>>> The latest HotPar >>>> https://www.usenix.org/conference/hotpar12/tech-schedule/workshop-programhad >>>> two interesting papers >>>> **** >>>> >>>> ** ** >>>> Parallel Programming for the >>>> Web<https://www.usenix.org/conference/hotpar12/parallel-programming-web> >>>> https://www.usenix.org/conference/hotpar12/parallel-programming-web**** >>>> >>>> and**** >>>> >>>> *Parallel Closures: A New Twist on an Old Idea * >>>> https://www.usenix.org/conference/hotpar12/parallel-closures-new-twist-old-idea >>>> **** >>>> >>>> ** ** >>>> >>>> These projects each address some important part of the general problem >>>> of adding parallelism and concurrency to JavaScript. **** >>>> >>>> ** ** >>>> >>>> Feedback is always appreciated.**** >>>> >>>> ** ** >>>> >>>> **- **Rick**** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> *From:* [email protected] [mailto: >>>> [email protected]] *On Behalf Of *Jussi Kalliokoski >>>> *Sent:* Monday, September 24, 2012 8:44 AM >>>> *To:* es-discuss >>>> *Subject:* Function#fork**** >>>> >>>> ** ** >>>> >>>> Hello everyone, >>>> >>>> I've been thinking a lot about parallel processing in the context of >>>> JavaScript, and this is really a hard problem. I'm very curious to hear >>>> what everyone's opinions are about it's problems and so forth, but I don't >>>> think an open question like that will give very interesting results, so I >>>> have an example problem for discussion (while it seems like a bad idea to >>>> me, and unlikely to ever get to the language, what I want to know is >>>> everyone's reasoning behind their opinions whether it's for or against). >>>> >>>> What if we introduce Function#fork(), which would call the function in >>>> another thread that shares state with the current one (how much state it >>>> shares is an open question I'd like to hear ideas about, but one >>>> possibility is that only the function arguments are shared) using a similar >>>> signature to Function#call except that the first argument would be a >>>> callback, which would have error as its first argument (if the forked >>>> function throws with the given arguments, it can be controlled) and the >>>> return value of the forked function as the second argument. >>>> >>>> * What are the technical limitations of this? >>>> * What are the bad/good implications of this on the language users? >>>> * Better ideas? >>>> * etc. >>>> >>>> I have a detailed example of showing Function#fork in action [1] (I was >>>> supposed to make a simplified test, but got a bit carried away and made it >>>> do "parallel" fragment shading), it uses a simple fill-in for the >>>> Function#fork using setTimeout instead of an actual thread. >>>> >>>> Cheers, >>>> Jussi >>>> >>>> [1] https://gist.github.com/3775697**** >>>> >>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
