I keep hoping that JS would evolve to support the actor model, a la Erlang/Elixir, with their process based persistence, concurrency via message passing, etc. It just seems so much simpler and tractable than this proposal.
A Taste of JavaScript's New Parallel Primitives
11–20 of 107 posts
Re: A Taste of JavaScript's New Parallel Primitives
#12> 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
The issue is emscripten uses a different LLVM version than we do; so it can work, but it's got some rough edges.
We want both compile to JS and compile to wasm to work well, the work just isn't done yet.
Re: A Taste of JavaScript's New Parallel Primitives
#13I'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 deter…
Here's a typed objects system for JS which uses ArrayBuffers for backing storage, in future it will also support SharedArrayBuffer - https://github.com/codemix/reign (disclaimer: I wrote this).
Re: A Taste of JavaScript's New Parallel Primitives
#14The 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…
SharedArrayBuffer only allows plain typed (byte) arrays to be shared at least. Arbitrary javascript objects can't be shared, so there's a very clear division about what can get affected by other threads and what can't. You don't have to worry about whether existing libraries are thread-safe, etc.
Re: A Taste of JavaScript's New Parallel Primitives
#15You 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…
> I understand exactly when and where my javascript code will be interrupted
That's why callbacks, promises, async/await and all that are neither multitasking, nor multithreading. They are all about control, while multithreading is all about parallelism and is essentially a very low-level specialized thing, that nobody should be using, unless absolutely necessary.
Re: A Taste of JavaScript's New Parallel Primitives
#16I keep hoping that JS would evolve to support the actor model, a la Erlang/Elixir, with their process based persistence, concurrency via message passing, etc. It just seems so much simpler and tractable than this proposal.
That wouldn't do much for the use cases they want to use it (multimedia, games, number-crunching etc as in the example in TFA)
Re: A Taste of JavaScript's New Parallel Primitives
#17> 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.
I would be very surprised if Rust doesn't target WebAssembly sometime in the future. It's just such a good fit. If I remember correctly there are already talks about doing MIR->WASM.
Re: A Taste of JavaScript's New Parallel Primitives
#18On my grossly overpowered workstation, I can only crank the number of workers in the Mandelbrot demo to 20 [1]. Attempting to go beyond 20, the console reports:
RangeError: out-of-range index for atomic access
[1] https://axis-of-eval.org/blog/mandel3.html?numWorkers=20
Re: A Taste of JavaScript's New Parallel Primitives
#19The 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…
SharedArrayBuffer only allows plain typed (byte) arrays to be shared at least. Arbitrary javascript objects can't be shared, so there's a very clear division about what can get affected by other threads and what can't. You don't have to worry about whether existing libraries are thread-safe, etc.
Not only that, but if you don't need "Shared" array buffers (meaning more than one thread using it at once) you can use "Transferrable" [1] ArrayBuffers.
It's just a zero-copy transfer to a worker (or from a worker) but it makes sure the "sender" doesn't have access to the memory any more.
It's incredibly easy to use, avoids all the common issues and pitfalls with shared memory, and being zero-copy it's stupidly fast.
Obviously it's not a replacement for true shared memory, but i've used it in the past to do some image processing in the browser (broke the image into chunks, and transferred each chunk to a worker to process, then return and stitch them all back together).
[1]https://developer.mozilla.org/en-US/docs/Web/API/Transferabl...
Re: A Taste of JavaScript's New Parallel Primitives
#20I keep hoping that JS would evolve to support the actor model, a la Erlang/Elixir, with their process based persistence, concurrency via message passing, etc. It just seems so much simpler and tractable than this proposal.
In some ways web workers feel a bit like actors. granted a poor man's actor.