3 ms·

I think they mostly mean the overhead of (de)serialization from/into JSON. It's also hard to pass binary data that way.

by odiroot 12y ago

polskibus 12y ago
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.
jewel 12y ago
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.
- benjaminjackman 12y ago
  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_API/Advanced_concepts_and_examples#Passing_data_by_transferring_ownership_%28transferable_objects%29 https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
benjaminjackman 12y ago
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_API/Advanced_concepts_and_examples#Passing_data_by_transferring_ownership_%28transferable_objects%29 https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... 2: https://github.com/real-logic/simple-binary-encoding https://github.com/real-logic/simple-binary-encoding

I think they mostly mean the overhead of (de)serialization from/into JSON. It's also hard to pass binary data that way.

by odiroot 12y ago

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.

jewel 12y ago

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.

benjaminjackman 12y ago
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_API/Advanced_concepts_and_examples#Passing_data_by_transferring_ownership_%28transferable_objects%29 https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

benjaminjackman 12y ago

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_API/Advanced_concepts_and_examples#Passing_data_by_transferring_ownership_%28transferable_objects%29 https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... 2: https://github.com/real-logic/simple-binary-encoding https://github.com/real-logic/simple-binary-encoding