On Mon, Sep 24, 2012 at 9:19 PM, Mark S. Miller <[email protected]> wrote:
> > > 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 ;). > Heheh, luckily there are better technologies available for this exact use case. :D > > >> [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
