Function#fork

Mon Sep 24 11:39:37 PDT 2012

On Mon, Sep 24, 2012 at 9:19 PM, Mark S. Miller <erights at google.com> wrote:

>
>
> On Mon, Sep 24, 2012 at 9:17 AM, Jussi Kalliokoski <
> jussi.kalliokoski at gmail.com> 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 <slightlyoff at google.com>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 <
>>> jussi.kalliokoski at gmail.com> 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 <rick.hudson at intel.com>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:* es-discuss-bounces at mozilla.org [mailto:
>>>>> es-discuss-bounces at mozilla.org] *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
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120924/fd6b9842/attachment-0001.html>