Function#fork

[Mark S. Miller]

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 ;).



> [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/bb8806c3/attachment.html>