A Taste of JavaScript's New Parallel Primitives
hacks.mozilla.org
A Taste of JavaScript's New Parallel Primitives
1–10 of 107 posts
Re: A Taste of JavaScript's New Parallel Primitives
#2> This leads to the following situation where the main program and the worker both reference the same memory, which doesn’t belong to either of them:
If only Mozilla had some technology that could deal with ownership of memory...
Seriously, if rust doesn't have an ASM.js optimized target yet, it really should.
Re: A Taste of JavaScript's New Parallel Primitives
#3You know, I'm not entirely sure how I feel about this. On the one hand: yeah, I get that having really multithreaded stuff is pretty handy, especially for certain computationally-bound tasks.
On the other hand, I quite like the single-threadedness of javascript. Promises-based systems (or async/await) give us basically cooperative multitasking anyway to break up long-running (unresponsive) threads without worrying about mutexes and semaphores. I understand exactly when and where my javascript code will be interrupted, and I don't need to wrap blocks in atomic operation markers extraneously.
I've written plenty multithreaded code, starting with old pthreads stuff and eventually moving on to Java (but my own experience with threaded stuff is limited mainly to C and Java), and it can be a real pain. I guess limiting shared memory to explicitly named blocks means you don't have as much to worry about vis-a-vis nonreentrant code messing up your memory space.
That said, it is a pretty useful construct, and I see where this can benefit browser-based games dev in particular (graphics can be sped up a lot with multicore rendering, I bet).
Re: A Taste of JavaScript's New Parallel Primitives
#4You know, I'm not entirely sure how I feel about this. On the one hand: yeah, I get that having really multithreaded stuff is pretty handy, especially for certain computationally-bound tasks. On the other hand, I quite like the single-threadedness of javascript. Promises-based systems (or async/await) give us basically cooperative multitasking anyway to break up long-running (unresponsive) threads without worrying ab…
Welp, the idea is portability. This is a bridge between other platforms into JS, and -- as you mentioned -- its usage is largely specialized.
Most people don't really know what typed arrays are, but they're in ES6 nevertheless.
Re: A Taste of JavaScript's New Parallel Primitives
#5You know, I'm not entirely sure how I feel about this. On the one hand: yeah, I get that having really multithreaded stuff is pretty handy, especially for certain computationally-bound tasks. On the other hand, I quite like the single-threadedness of javascript. Promises-based systems (or async/await) give us basically cooperative multitasking anyway to break up long-running (unresponsive) threads without worrying ab…
[deleted]
Re: A Taste of JavaScript's New Parallel Primitives
#6> This leads to the following situation where the main program and the worker both reference the same memory, which doesn’t belong to either of them: If only Mozilla had some technology that could deal with ownership of memory... Seriously, if rust doesn't have an ASM.js optimized target yet, it really should.
If rust can be compiled to LLVM, then emscripten can be the backend to asm JS
Re: A Taste of JavaScript's New Parallel Primitives
#7This is the last piece needed to allow multi-threaded code with shared state to emscripten [0]. A very good thing indeed
[0] http://kripken.github.io/emscripten-site/docs/porting/guidel...
Re: A Taste of JavaScript's New Parallel Primitives
#8This is the last piece needed to allow multi-threaded code with shared state to emscripten [0]. A very good thing indeed
[0] http://kripken.github.io/emscripten-site/docs/porting/guidel...
Re: A Taste of JavaScript's New Parallel Primitives
#9I'm excited to see progress in the area of JS concurrency, but I'm not sure how useful this is going to be. It lets me share ArrayBuffers between workers, but all of my data is in the form of Objects, not primitive arrays.
One place where I would like to use this is for collision detection, like in this example: http://codepen.io/kgr/pen/GoeeQw
But I'm relying on objects with polymorphic intersects() methods to determine if they intersect with each other, and once I encode everything up as arrays, I lose the convenience and power of objects.
Re: A Taste of JavaScript's New Parallel Primitives
#10The saving grace of JavaScript's everything-is-async, single threaded model was that it was just slightly less difficult to reason about than multiple threads and shared state. (Though I'd say that's debatable...)
My guess is that, despite the sugar coating that JavaScript's async internals have received of late, writing stable multi-threaded code with JavaScript is going to be hard.
JavaScript now has the safety of multi-threaded code with the ease of asynchronicity!