3 ms·

Every mainstream JS runtime has some sort of background garbage collection and parsing/compilation, but for any execution that has to interact with JavaScript h

Every mainstream JS runtime has some sort of background garbage collection and parsing/compilation, but for any execution that has to interact with JavaScript heap or stack state you’re still in single threaded territory. SharedArrayBuffer can help if you’re willing to give up on JavaScript objects entirely, and for WebAssembly this is less of a burden, but that’s not going to help you perform rendering on most web apps concurrently. JSCore goes a little bit further and can run javascript in the same runtime instance on multiple threads with some significant limitations, but this isn’t exposed to developers on Safari.

eyelidlessness 5y ago
It really depends on your use case and on how you design for threads. Quite a lot of data types can be sent by postMessage, and a decent amount of them are transferable. If your use case doesn’t require passing around functions (and if you can’t find a way to work around that), many workloads which would benefit from multithreading in another language will likely similarly benefit from JS threads (Web Workers, Node’s Worker Threads, etc). The biggest determining factor at that point is whether the overhead of instantiating them, and of message passing, is worth it. (And the latter is often a lot less than people realize; in my experience it’s almost universally faster than crossing a WASM/FFI-type of boundary.)
- johncolanduoni 5y ago
  On what engine have you seen postmessage be faster than a WASM/JS boundary? It’s at least an order of magnitude slower on Chrome/V8, even when a call needs to pass significant strings into WASM (microseconds vs hundreds of ns). It’s also worth noting that postmessage is itself an FFI boundary that requires a JS to C++ transition on every engine I’m aware of.
  - eyelidlessness 5y ago
    I’ve seen in on Node 16 (also V8) trying both purpose-built and custom bindings to libraries built in Rust, C, C++ and Go. All of the purpose built libraries acknowledge there’s an overhead to cross the native/WASM boundary. In my experience, measuring extensively, postMessage with native runtime objects outperforms any other ser/de solution that works with JS values.

eyelidlessness 5y ago

It really depends on your use case and on how you design for threads. Quite a lot of data types can be sent by postMessage, and a decent amount of them are transferable. If your use case doesn’t require passing around functions (and if you can’t find a way to work around that), many workloads which would benefit from multithreading in another language will likely similarly benefit from JS threads (Web Workers, Node’s Worker Threads, etc). The biggest determining factor at that point is whether the overhead of instantiating them, and of message passing, is worth it. (And the latter is often a lot less than people realize; in my experience it’s almost universally faster than crossing a WASM/FFI-type of boundary.)

johncolanduoni 5y ago
On what engine have you seen postmessage be faster than a WASM/JS boundary? It’s at least an order of magnitude slower on Chrome/V8, even when a call needs to pass significant strings into WASM (microseconds vs hundreds of ns). It’s also worth noting that postmessage is itself an FFI boundary that requires a JS to C++ transition on every engine I’m aware of.
- eyelidlessness 5y ago
  I’ve seen in on Node 16 (also V8) trying both purpose-built and custom bindings to libraries built in Rust, C, C++ and Go. All of the purpose built libraries acknowledge there’s an overhead to cross the native/WASM boundary. In my experience, measuring extensively, postMessage with native runtime objects outperforms any other ser/de solution that works with JS values.