3 ms·

I work with the node source and I have made C/C++ based node modules. Threading at the JS level in node is really ineffective. V8 has a global lock on all JS o

by hacknat 13y ago

I work with the node source and I have made C/C++ based node modules. Threading at the JS level in node is really ineffective. V8 has a global lock on all JS objects that prevent them from being passed between threads. The only way to allow threading is to serialize and deserialize the objects into new "isolates" (V8 language). V8 does this for some pretty obvious reasons, you wouldn't really want to allow threading at the JS level in a browser, now would you. You can use threads if you dive down into C++ land, but event then, you should have a really good reason for doing so, because if you're only manipulating objects for processing you're going to have to serialize into a C++ data-structure, process, and then serialize into a JS object. Threads in node are good for doing process intensive work that doesn't require any two way input from the main event loop, otherwise it's very unlikely to be worth your time or effort. This is why fibers are kind of silly for node and is also why process intensive programs should most likely be avoided in node (with rare exception). Please use node for what it is good at; it's a short lived connection proxy maven, and good at ancillary front-end work that requires complex state transitions (i.e. mobile). Working it into a monolithic stack is just asking for trouble and pain. No serious architect should consider it for a large monolithic rendering stack.

audreyt 13y ago
Agreed on all accounts, with one small, specific clarification: If computation is local to each of many long-running threads, and the two-way messages being passed around is small enough (so the serialization overhead is negligible), then threads do perform better on multi-core machines than alternative models. EtherCalc.org is one such use case: http://aosabook.org/en/posa/from-socialcalc-to-ethercalc.html#multi-core-scaling http://aosabook.org/en/posa/from-socialcalc-to-ethercalc.htm...
- hacknat 13y ago
  Agreed.
derefr 13y ago
> V8 does this for some pretty obvious reasons, you wouldn't really want to allow threading at the JS level in a browser, now would you. I'd really like to have Erlang-style actors at the JS level in a browser, which is predicated on having threads.
- arxpoetica 13y ago
  > you wouldn't really want to allow threading at the JS level in a browser I was wondering over this same statement. It seems rather...presumptuous?
rektide 13y ago
Don't Isolates also allow and support the use of Transferables? Objects can only be in one isolated thread or another, but I thought the purpose of Transferables was to get rid of the need to ser-deser them? Which mates well with what one of the projects in the article is up to: audreyt's node-webworker-threads. Webworkers extend webmessaging, so it's- as you talk about- about passing objects to one another. Certainly Webworkers can and have been implemented without threads. Node-webworkers does just that, but it uses websockets to do inter-worker communication: it cannot leverage Transferables that causes the need to copy objects. Would that there be a common process where postMessage() could transfer an object from one owner to another! I highly recommend learning and using webworkers for all developers- they are a huge part of the future of the web- and anything that Node can do to nurture and make common and harmonious it's existence with the de-facto well defined means for multi-processing. I cannot but see as a good thing. I also cannot help but think that perhaps multi-threading is a fine and advantageous way to achieve webworkers intercommunicating form of multi-processing: it enables Transferables, where ser-deser can be avoided.
- hacknat 13y ago
  Transferables are fast, but they are still a copy operation.
jenandre 13y ago
+1. If you want threads, build a node c++ addon that manages your threads/high performance work (and try not to pass too much back and forth with your Javascript, because of the performance overhead of marshaling described above). Which means you are just writing a lot of C++, and your javascript simply becomes a convenient interface to start/stop the processing and script actions on values emitted from your c++ addon. Or, like everyone else recommends: use processes and ipc (e.g., the cluster module).
- memracom 13y ago
  Note that on Linux, the performance difference between processes and threads is an awful lot smaller than it was when threads first came into the world. This is another case where someone invented a better idea for performance reasons, and the people in charge of the old idea (processes) realized that they could do a lot better. So they did. And nowadays few people have a real need to squeeze every bit of performance out of a server. For most of us it is a question of buying one or two more servers. Only the Googles of the world really need to deal with this kind of performance tweaking, and if you look at what they are doing, it does not include Javascript.

by hacknat 13y ago

audreyt 13y ago

Agreed on all accounts, with one small, specific clarification: If computation is local to each of many long-running threads, and the two-way messages being passed around is small enough (so the serialization overhead is negligible), then threads do perform better on multi-core machines than alternative models. EtherCalc.org is one such use case: http://aosabook.org/en/posa/from-socialcalc-to-ethercalc.html#multi-core-scaling http://aosabook.org/en/posa/from-socialcalc-to-ethercalc.htm...

hacknat 13y ago
Agreed.

derefr 13y ago

> V8 does this for some pretty obvious reasons, you wouldn't really want to allow threading at the JS level in a browser, now would you. I'd really like to have Erlang-style actors at the JS level in a browser, which is predicated on having threads.

arxpoetica 13y ago
> you wouldn't really want to allow threading at the JS level in a browser I was wondering over this same statement. It seems rather...presumptuous?

rektide 13y ago

Don't Isolates also allow and support the use of Transferables? Objects can only be in one isolated thread or another, but I thought the purpose of Transferables was to get rid of the need to ser-deser them? Which mates well with what one of the projects in the article is up to: audreyt's node-webworker-threads. Webworkers extend webmessaging, so it's- as you talk about- about passing objects to one another. Certainly Webworkers can and have been implemented without threads. Node-webworkers does just that, but it uses websockets to do inter-worker communication: it cannot leverage Transferables that causes the need to copy objects. Would that there be a common process where postMessage() could transfer an object from one owner to another! I highly recommend learning and using webworkers for all developers- they are a huge part of the future of the web- and anything that Node can do to nurture and make common and harmonious it's existence with the de-facto well defined means for multi-processing. I cannot but see as a good thing. I also cannot help but think that perhaps multi-threading is a fine and advantageous way to achieve webworkers intercommunicating form of multi-processing: it enables Transferables, where ser-deser can be avoided.

hacknat 13y ago
Transferables are fast, but they are still a copy operation.

jenandre 13y ago

+1. If you want threads, build a node c++ addon that manages your threads/high performance work (and try not to pass too much back and forth with your Javascript, because of the performance overhead of marshaling described above). Which means you are just writing a lot of C++, and your javascript simply becomes a convenient interface to start/stop the processing and script actions on values emitted from your c++ addon. Or, like everyone else recommends: use processes and ipc (e.g., the cluster module).

memracom 13y ago
Note that on Linux, the performance difference between processes and threads is an awful lot smaller than it was when threads first came into the world. This is another case where someone invented a better idea for performance reasons, and the people in charge of the old idea (processes) realized that they could do a lot better. So they did. And nowadays few people have a real need to squeeze every bit of performance out of a server. For most of us it is a question of buying one or two more servers. Only the Googles of the world really need to deal with this kind of performance tweaking, and if you look at what they are doing, it does not include Javascript.