3 ms·

> try using actors for parallelism Erlang > or MPI for concurrency Go uses channels as a message passing interface for the "composition of independently exec

> try using actors for parallelism Erlang > or MPI for concurrency Go uses channels as a message passing interface for the "composition of independently executing processes"

seanmcdirmid 12y ago
Erlang is about concurrency, not parallelism; ditto for Go Channels. MPI was designed for parallelism in the HPC sector, not concurrency for distributed servers. Saying concurrency and parallelism are equivalent basically invalidates all design decisions made by these systems.
- stefantalpalaru 12y ago
  > Erlang is about concurrency, not parallelism They make full use of all CPU cores since they implemented SMP support: http://erlang.2086793.n4.nabble.com/Some-facts-about-Erlang-and-SMP-td2108770.html http://erlang.2086793.n4.nabble.com/Some-facts-about-Erlang-... > ditto for Go Channels Go has a user-space M:N scheduler that distributes its "goroutines" among multiple OS threads and therefore multiple cores.
- rdtsc 12y ago
  > Erlang is about concurrency, not parallelism; Erlang is about both. Those are not either or. Concurrency sits at a higher level of abstraction -- at the problem domain. "I'll create an actor for this request, another actor for that, maybe another one for monitoring". These are concurrent units. Parallelism happens if my machine has more than one CPU and these concurrency units will actaully execute at the same time. Or maybe I have a single CPU only. I'll have not parallelism. They'll be sequenced and scheduled in and out of the single CPU in some small or larger time slices. But they'll not execute in parallel. So maybe I am running my machine in 1989 (Erlang was doing work back then too) with only a single CPU. I still want to create many concurrent units of work. Or maybe I am running in 2015 and I have 64 core machine and I specifically choose Erlang because I expect to get lots of parallelism for cheap as my concurrent units are largely independent of each other.
  - seanmcdirmid 12y ago
    It really depends on what you are doing. If you are processing requests concurrently, parallelism is a nice benefit, but the requirement is to do things at the same time correctly with resource contentions involved. Parallelism is more about breaking a job into bits so it goes faster...e.g. what is done in the HPC and Big Data worlds with MPI, CUDA, MapReduce, ... Concurrency is necessary property of the work as defined, parallelism is an opportunistic property. Confusing the two concepts can lead to people trying to do HPC work with Erlang. If you are working on an HPC workload, you wouldn't choose Erlang, but you might get a happy speed up for a standard distributed application. Parallelism is strictly about performance, concurrency is about correctness. When you go off and do a HPC or big data program, you might play with MPI, CUDA, MapReduce, or maybe just roll something yourself. No one goes...we should do that in Erlang! Likewise, when you go off and do a concurrent distributed system, Actors make a lot of sense given the concurrency requirements involved (who would think of using CUDA for that?). Perhaps the problem is not about concurrency and parallelism, but different kinds of computations.
    - Xixi 12y ago
      It's a semantic debat, but you seem to redefine parallelism as HPC. I respectfully disagree, parallelism is not necessarily about getting faster, it is really about actually executing computations simultaneously. Erlang uses parallelism for fault-tolerance purposes, because you need several physical machines running in parallel on different sites to achieve outstanding fault-tolerance. MPI/CUDA/MapReduce uses parallelism for performance reasons. I do not know if it is true as I couldn't find the source, but I remember reading that aircrafts run all computations in parallel on three different architectures (Power and two others), using three different algorithms, to ensure that the results are not compromised either by a faulty algorithm, or a CPU bug. In that case parallelism is used for safety.
      - seanmcdirmid 12y ago
        Sigh...and this is why we are here :) From wiki [1]: > Parallel computing is a form of computation in which many calculations are carried out simultaneously, operating on the principle that large problems can often be divided into smaller ones, which are then solved concurrently ("in parallel"). ... Parallel computer programs are more difficult to write than sequential ones,[5] because concurrency introduces several new classes of potential software bugs, of which race conditions are the most common. And the article for concurrency [2]: > In computer science, concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. The computations may be executing on multiple cores in the same chip, preemptively time-shared threads on the same processor, or executed on physically separated processors. [1] http://en.wikipedia.org/wiki/Parallel_computing http://en.wikipedia.org/wiki/Parallel_computing [2] http://en.wikipedia.org/wiki/Concurrency_(computer_science) http://en.wikipedia.org/wiki/Concurrency_(computer_science) Concurrency is a problem (doing things at the same time leads to resource contention), while parallelism is a performance technique. Fault tolerance is something else altogether, and can apply to concurrency problems as well as parallel speedups. Doing things in parallel as a form of redundancy isn't really parallelism...in general, the word parallelism != "in parallel" while concurrency != "concurrently," though they are definitely related. Phew.

> try using actors for parallelism Erlang > or MPI for concurrency Go uses channels as a message passing interface for the "composition of independently executing processes"

seanmcdirmid 12y ago

Erlang is about concurrency, not parallelism; ditto for Go Channels. MPI was designed for parallelism in the HPC sector, not concurrency for distributed servers. Saying concurrency and parallelism are equivalent basically invalidates all design decisions made by these systems.

stefantalpalaru 12y ago
> Erlang is about concurrency, not parallelism They make full use of all CPU cores since they implemented SMP support: http://erlang.2086793.n4.nabble.com/Some-facts-about-Erlang-and-SMP-td2108770.html http://erlang.2086793.n4.nabble.com/Some-facts-about-Erlang-... > ditto for Go Channels Go has a user-space M:N scheduler that distributes its "goroutines" among multiple OS threads and therefore multiple cores.
rdtsc 12y ago
> Erlang is about concurrency, not parallelism; Erlang is about both. Those are not either or. Concurrency sits at a higher level of abstraction -- at the problem domain. "I'll create an actor for this request, another actor for that, maybe another one for monitoring". These are concurrent units. Parallelism happens if my machine has more than one CPU and these concurrency units will actaully execute at the same time. Or maybe I have a single CPU only. I'll have not parallelism. They'll be sequenced and scheduled in and out of the single CPU in some small or larger time slices. But they'll not execute in parallel. So maybe I am running my machine in 1989 (Erlang was doing work back then too) with only a single CPU. I still want to create many concurrent units of work. Or maybe I am running in 2015 and I have 64 core machine and I specifically choose Erlang because I expect to get lots of parallelism for cheap as my concurrent units are largely independent of each other.
- seanmcdirmid 12y ago
  It really depends on what you are doing. If you are processing requests concurrently, parallelism is a nice benefit, but the requirement is to do things at the same time correctly with resource contentions involved. Parallelism is more about breaking a job into bits so it goes faster...e.g. what is done in the HPC and Big Data worlds with MPI, CUDA, MapReduce, ... Concurrency is necessary property of the work as defined, parallelism is an opportunistic property. Confusing the two concepts can lead to people trying to do HPC work with Erlang. If you are working on an HPC workload, you wouldn't choose Erlang, but you might get a happy speed up for a standard distributed application. Parallelism is strictly about performance, concurrency is about correctness. When you go off and do a HPC or big data program, you might play with MPI, CUDA, MapReduce, or maybe just roll something yourself. No one goes...we should do that in Erlang! Likewise, when you go off and do a concurrent distributed system, Actors make a lot of sense given the concurrency requirements involved (who would think of using CUDA for that?). Perhaps the problem is not about concurrency and parallelism, but different kinds of computations.
  - Xixi 12y ago
    It's a semantic debat, but you seem to redefine parallelism as HPC. I respectfully disagree, parallelism is not necessarily about getting faster, it is really about actually executing computations simultaneously. Erlang uses parallelism for fault-tolerance purposes, because you need several physical machines running in parallel on different sites to achieve outstanding fault-tolerance. MPI/CUDA/MapReduce uses parallelism for performance reasons. I do not know if it is true as I couldn't find the source, but I remember reading that aircrafts run all computations in parallel on three different architectures (Power and two others), using three different algorithms, to ensure that the results are not compromised either by a faulty algorithm, or a CPU bug. In that case parallelism is used for safety.
    - seanmcdirmid 12y ago
      Sigh...and this is why we are here :) From wiki [1]: > Parallel computing is a form of computation in which many calculations are carried out simultaneously, operating on the principle that large problems can often be divided into smaller ones, which are then solved concurrently ("in parallel"). ... Parallel computer programs are more difficult to write than sequential ones,[5] because concurrency introduces several new classes of potential software bugs, of which race conditions are the most common. And the article for concurrency [2]: > In computer science, concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. The computations may be executing on multiple cores in the same chip, preemptively time-shared threads on the same processor, or executed on physically separated processors. [1] http://en.wikipedia.org/wiki/Parallel_computing http://en.wikipedia.org/wiki/Parallel_computing [2] http://en.wikipedia.org/wiki/Concurrency_(computer_science) http://en.wikipedia.org/wiki/Concurrency_(computer_science) Concurrency is a problem (doing things at the same time leads to resource contention), while parallelism is a performance technique. Fault tolerance is something else altogether, and can apply to concurrency problems as well as parallel speedups. Doing things in parallel as a form of redundancy isn't really parallelism...in general, the word parallelism != "in parallel" while concurrency != "concurrently," though they are definitely related. Phew.