Will Spidermonkey be rewritten in Rust eventually? Sidenote: WebGL 2.0 should come with ASTC support to be relatively future-proof.
That is too far in the future to see.
The Path to Parallel JavaScript
31–40 of 58 posts
Re: The Path to Parallel JavaScript
#32What'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!
Forgive me if my comment seems ignorant, as I've had experience with MPI and threaded code, but not professionally. I also do not provide any numbers or profiles. I would think message passing in terms of MPI is acceptable, because "the cost of copying" is insignificant to "the cost of network latency." When you have very little overhead (multiple threads performing atomic operations on shared memory), then "the cost…
Which existing C++ code are you referring to? It seems like a bad idea to compromise the soundness of Javascript to do whatever it is you are talking about doing. I don't think that legacy C++ code is something that should be causing anything to bend.
Re: The Path to Parallel JavaScript
#33Earlier quoted context omitted.
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-...
Interesting. I wonder how they handle incremental rendering though. Only the forward-path is described in your reference [2].
As far as I can tell there is nothing unusual or difficult here. Servo's incremental layout implementation is here: https://github.com/servo/servo/blob/master/components/layout...
Re: The Path to Parallel JavaScript
#34Does anyone know what is the origin of async/await? It's very convenient for simple cases, but it makes it very hard to mix synchronous and async code(C#).
How does it make it difficult?
You can only call async functions inside async functions.
See also What color is your function? http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
Re: The Path to Parallel JavaScript
#35This is nice for some pretty limited use cases, but the most common use case for multithreading in app-like programs (which is what Worker-based apps presumably service: these are not documents) is removing latency from the UI thread. But as long as only the main thread can touch the UI, and the main thread also can't access shared memory, this limits uses of this to scenarios where copying the entire render state from a Worker is reasonably fast — in which case, Workers currently already solve the problem. This proposed implementation of shared memory doesn't actually solve one of the big remaining needs for shared memory, which is when it's prohibitively expensive to copy state between a Worker thread and the UI thread at 60fps.
For example, Workers aren't particularly useful for games in their current iteration: the overhead of copying the state of the world back to the rendering thread is high. This is exactly the problem that shared memory would solve, were it not limited to Workers. This puts web export (or even primary web-based game authorship) at a significant disadvantage as compared to native apps: native code can share memory, and web-based implementations can't. In many cases architectures that are optimal for shared-memory threading are pathological when the rendering thread requires copies, meaning that threading gets thrown out the window for web. Even with asm.js-compiled "near-native" performance on the single core, you can only use 25% of the available CPU if you can't use multithreading. A 4x performance hit is the difference between 60fps and 15fps... Or 15fps and ~4fps.
The title of the blog post got me pretty excited, but the proposal is fairly disappointing in terms of unlocking better performance for web apps. The use cases here are pretty limited to things like CPU-bound number crunching, and I doubt too many people are running machine learning algorithms in a browser as compared to the number people who're using browsers to, y'know, render UIs. By all means scope the problem down to sharing primitive data in ArrayBuffers — we can build abstractions on top of that! — but limiting it to Worker threads makes it near-useless for most web applications. Workers already solve the use cases for UIs that can tolerate copies between the UI thread and the Worker threads, and this proposal doesn't allow us to solve needs for UIs that can't.
Re: The Path to Parallel JavaScript
#36Great 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…
The proposal only is for sharing memory in between Worker threads, which can't access the DOM (which also means canvas, WebGL, etc aren't able to be accessed). It doesn't do anything to help make UIs smoother: you still have to copy to transfer data from the UI thread to the Worker threads and back. If that isn't a problem, then Workers as-is will unblock your UI: you can already do this with Workers as they're implemented today.
All that this does is make algorithms running inside Workers faster. It doesn't unblock UIs, since Workers already do that if you're willing to accept copying. If copying back and forth from the main UI thread is too slow, this proposal won't change that.
Re: The Path to Parallel JavaScript
#37Will Spidermonkey be rewritten in Rust eventually? Sidenote: WebGL 2.0 should come with ASTC support to be relatively future-proof.
Note that JITing compilers gain a lot less from Rust's safety guarantees than most code: you can easily JIT some code that breaks one of the safety properties that Rust ordinarily defends.
Re: The Path to Parallel JavaScript
#38What'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!
When you have a large amount of data that needs to be sequentially iterated through by multiple threads — e.g. in games, where the UI thread and the physics thread are often entirely separate but read off a shared world state — message passing falls over. The copies are just too expensive.
Message passing is great for things that use small amounts of data but lots of CPU, though!
Re: The Path to Parallel JavaScript
#39Great 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…
Re-pasting a link that was buried further down in the discussion. Transferable objects provide zero copy sending/receiving of large amounts of binary data.
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
Re: The Path to Parallel JavaScript
#40I would love to see a channel primitive similar to Golang's. They really seem to have hit the nail on the head with that one.
The CSP model is very nice, but I don't think that what this proposal is aiming for. CSP is more about concurrency, while the post makes it clear they are looking at parallelism. This is more addressing "things that appear to be single threaded but run faster" like image analysis, for instance.
They're obviously separate concepts, but tangentially related. Even in Go you'll learn that sometimes introducing multithreading to a concurrent application will actually reduce your performance due to reconciliation of context-switching within the application.
Javascript already has its own inherent concurrency, obviously, but it's not outlandish to say that introducing a goroutine/coroutine concept would be a lot more elegant and manageable.