4 ms·

what about just using the built in cluster functionality already in nodejs? I've used it many times with great results and it is really easy to implement.

by ldehaan 11y ago

ignoramous 11y ago
The clustering module on NodeJs cannot compete with speed that threading, or STM, or Actors offer. The thing with NodeJs is, it is not suited for CPU bound workloads. It's a great fit for I/O bound workloads (where most of the hardwork is done by, say, a DB). Process to process communication has tremendous cost, although shared-memory does make that faster, but at the cost of complicating the interaction. Message-queue (ZeroMQ) based interaction also an option but, by definition, it cannot be as fast as languages that have concurrency support built-in. Reasoning about concurrency is hard, and languages like Go (via CSP), Erlang and Scala (via Actors), Java (via Threads), Rust, and Clojure (via STM) take different approaches to make this less of a pain. CSP and Actors are what seem the most 'natural' of solutions. And that's a major reason why Go and Erlang are frontrunners in the concurrency race.
- pka 11y ago
  I would say the most natural is STM - you don't need to change much, just wrap your concurrent, shared memory accessing code in a STM transaction, be careful with IO (or use a language which prohibits IO in a STM block like Haskell) and you are done. Actors are pretty nice when it comes to distributed services, and Erlang/OTP is pretty much uncontested here. Threads with manual locking are only useful when speed is really important, but this is somewhat of a moot point when it comes to concurrency. Both STM and Actors perform slower (starvation, message copying overhead). Here [0] is a nice, in-depth discussion about some of the different approaches to concurrency. [0] https://plus.google.com/109566665911385859313/posts/FAmNTExSLtz https://plus.google.com/109566665911385859313/posts/FAmNTExS...
  - ignoramous 11y ago
    Interesting point there. Latency vs Throughput. Using green-threads (Quasar on JVM) might be the best of both worlds then? Akka.io on JVM could pretty much do what Erlang can on BEAM, functionality wise. Although some people have raised concerns over it being a "pseudo" solution and that it is a no match for Erlang.

what about just using the built in cluster functionality already in nodejs? I've used it many times with great results and it is really easy to implement.

by ldehaan 11y ago

what about just using the built in cluster functionality already in nodejs? I've used it many times with great results and it is really easy to implement.

ignoramous 11y ago

The clustering module on NodeJs cannot compete with speed that threading, or STM, or Actors offer. The thing with NodeJs is, it is not suited for CPU bound workloads. It's a great fit for I/O bound workloads (where most of the hardwork is done by, say, a DB). Process to process communication has tremendous cost, although shared-memory does make that faster, but at the cost of complicating the interaction. Message-queue (ZeroMQ) based interaction also an option but, by definition, it cannot be as fast as languages that have concurrency support built-in. Reasoning about concurrency is hard, and languages like Go (via CSP), Erlang and Scala (via Actors), Java (via Threads), Rust, and Clojure (via STM) take different approaches to make this less of a pain. CSP and Actors are what seem the most 'natural' of solutions. And that's a major reason why Go and Erlang are frontrunners in the concurrency race.

pka 11y ago
I would say the most natural is STM - you don't need to change much, just wrap your concurrent, shared memory accessing code in a STM transaction, be careful with IO (or use a language which prohibits IO in a STM block like Haskell) and you are done. Actors are pretty nice when it comes to distributed services, and Erlang/OTP is pretty much uncontested here. Threads with manual locking are only useful when speed is really important, but this is somewhat of a moot point when it comes to concurrency. Both STM and Actors perform slower (starvation, message copying overhead). Here [0] is a nice, in-depth discussion about some of the different approaches to concurrency. [0] https://plus.google.com/109566665911385859313/posts/FAmNTExSLtz https://plus.google.com/109566665911385859313/posts/FAmNTExS...
- ignoramous 11y ago
  Interesting point there. Latency vs Throughput. Using green-threads (Quasar on JVM) might be the best of both worlds then? Akka.io on JVM could pretty much do what Erlang can on BEAM, functionality wise. Although some people have raised concerns over it being a "pseudo" solution and that it is a no match for Erlang.