What's wrong with message passing though - MPI does it, Erlang does it - surely this paradigm can deliver good performance for data and task parallelism.
I hope Mozilla will continue experimenting with parallel js. Exciting times!
The Path to Parallel JavaScript
11–20 of 58 posts
Re: The Path to Parallel JavaScript
#12Great developments, since, imho, we really need multi-threading to make decent user-interfaces (ones without hick-ups due to blocking of the cpu-resource). I think what we need is immutable data-structures to be shareable between threads. This approach should also allow structural sharing between threads, allowing for efficient and safe data structures. Also, I could see a use for a mechanism where a thread creates a…
Anecdotally, I've found that most performance hick-ups don't come from computation blocking the ui, but from rendering one part of the ui blocking every other part from rendering.
The solution to that being parallel or async paint/layout, which is something I never hear mentioned (probably because it's a really hard problem).
Re: The Path to Parallel JavaScript
#13What's wrong with message passing though - MPI does it, Erlang does it - surely this paradigm can deliver good performance for data and task parallelism. I hope Mozilla will continue experimenting with parallel js. Exciting times!
I think they mostly mean the overhead of (de)serialization from/into JSON. It's also hard to pass binary data that way.
Re: The Path to Parallel JavaScript
#14What's wrong with message passing though - MPI does it, Erlang does it - surely this paradigm can deliver good performance for data and task parallelism. I hope Mozilla will continue experimenting with parallel js. Exciting times!
I think they mostly mean the overhead of (de)serialization from/into JSON. It's also hard to pass binary data that way.
Perhaps we need a fast copy mechanism for js to make message passing a more attractive option? Or make interpreter recognize such cases and do it under the hood/natively. Keeping my fingers crossed for a more functional approach.
Re: The Path to Parallel JavaScript
#15What's wrong with message passing though - MPI does it, Erlang does it - surely this paradigm can deliver good performance for data and task parallelism. I hope Mozilla will continue experimenting with parallel js. Exciting times!
I think they mostly mean the overhead of (de)serialization from/into JSON. It's also hard to pass binary data that way.
Would it work to have the data structures be copy-on-write? That way if the worker only reads then it's O(1), you just pass a reference to the worker.
I imagine it'd be a pain to write a garbage collector for something like that.
Re: The Path to Parallel JavaScript
#16Will Spidermonkey be rewritten in Rust eventually?
Sidenote: WebGL 2.0 should come with ASTC support to be relatively future-proof.
Re: The Path to Parallel JavaScript
#17What's wrong with message passing though - MPI does it, Erlang does it - surely this paradigm can deliver good performance for data and task parallelism. I hope Mozilla will continue experimenting with parallel js. Exciting times!
I think they mostly mean the overhead of (de)serialization from/into JSON. It's also hard to pass binary data that way.
This was mentioned in one line of the article so it's easy to miss, (I only recently heard about them which is why I caught it) but transfering binary data can actually be done with Transferrable objects already[1]
However for some high performance applications even that overhead might be too much because it requires allocation. Also having a regions of opt-in shared memory allows for higher level languages / patterns where message passing isn't the perfect answer.
An example off the top of my head that hits on both points (no-alloc + higher level patterns) would be to have one worker writing something encoded with SBE[2] into a shared buffer and having another consume it.
That will be 0 allocation (thus no gc-pressure) and very fast, for a class of applications avoiding GC pressure all together is really important.
It's a little sad that you can't share that back with the main thread. But it's not a deal breaker by any stretch, think about the main thread in the web like a classic gui event loop which you just use for rendering and you can still use transferable objects to get data to it and you should be fine.
1: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
Re: The Path to Parallel JavaScript
#18Great developments, since, imho, we really need multi-threading to make decent user-interfaces (ones without hick-ups due to blocking of the cpu-resource). I think what we need is immutable data-structures to be shareable between threads. This approach should also allow structural sharing between threads, allowing for efficient and safe data structures. Also, I could see a use for a mechanism where a thread creates a…
Anecdotally, I've found that most performance hick-ups don't come from computation blocking the ui, but from rendering one part of the ui blocking every other part from rendering. The solution to that being parallel or async paint/layout, which is something I never hear mentioned (probably because it's a really hard problem).
Servo is actually in the process of implementing a parallel layout engine[1][2]
1: http://en.wikipedia.org/wiki/Servo_(layout_engine) 2: http://pcwalton.github.io/blog/2014/02/25/revamped-parallel-...
Re: The Path to Parallel JavaScript
#19Earlier quoted context omitted.
I think they mostly mean the overhead of (de)serialization from/into JSON. It's also hard to pass binary data that way.
Would it work to have the data structures be copy-on-write? That way if the worker only reads then it's O(1), you just pass a reference to the worker. I imagine it'd be a pain to write a garbage collector for something like that.
Copy on write is already implemented-ish with transferable objects [1] (just copy then write the copy).
However, copy on write still requires allocation and for some applications that is a deal breaker.
1: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
Re: The Path to Parallel JavaScript
#20Great developments, since, imho, we really need multi-threading to make decent user-interfaces (ones without hick-ups due to blocking of the cpu-resource). I think what we need is immutable data-structures to be shareable between threads. This approach should also allow structural sharing between threads, allowing for efficient and safe data structures. Also, I could see a use for a mechanism where a thread creates a…
Anecdotally, I've found that most performance hick-ups don't come from computation blocking the ui, but from rendering one part of the ui blocking every other part from rendering. The solution to that being parallel or async paint/layout, which is something I never hear mentioned (probably because it's a really hard problem).
I believe that the Servo project (https://github.com/servo/servo) is attempting to address exactly this.