Depends. Erlang's scheduler is clever: if the receiver is asleep waiting on its inbox, sending to it will switch the running process to the receiver and back, all without hitting the scheduler logic. This is a great benefit for "thread" (in Erlang it's a process) pools, which are very very widely used in Erlang programs. It's really the best of both worlds: no Erlang context switch and it's completely transparent to one's codebase.

This isn't possible if the receiving process's inbox is non-empty or it's running. Then the cost should be around the same, assuming your C++ implementation is at the same level of quality as the Erlang VM.

Not a game programmer, but do a lot of multithreaded work. There's about 100000 ways to pass messages in c++, for some c++ is faster (purely bounded by cache communication), some erlang is faster, and for some it's hard to compare (send latency, receive latency, throughput, can all vary greatly).

That only applies for two processes running on a single machine, Erlang can automatically distribute workers (I believe) and in that case it's probably more about networking hardware than language.

Everything I've ever heard on that front is that Erlang should be considered a control layer which has any CPU-bound tasks run in C. Actors/message passing is a good synchronization primitive but there is apparently a whole host of issues with memory leaks regarding it in the "Erlang in Anger" e-book.

I personally lost interest in Erlang because of it only supporting actors as a concurrency mechanism. They're good for some things, and probably exceptionally good at what Erlang was designed for (Telecom systems), but I think they're just one tool in the toolbox. If the recommended solution for CPU-bound tasks is to start writing C, I have to wonder if there's a better way.

I'm not a game programmer, but I've got plenty of experience with parallel programming.

The answer is that either message passing or shared memory can be slower or faster. The architecture of your program probably matters more, though obviously some problems lend themselves more to a shared memory solution and some more to a message passing approach (and many benefit from hybrid solutions).

The main cost factor for message passing approaches is communication overhead. The main cost factors for shared memory are contention and fighting the memory hierarchy (keep in mind that even with shared memory, inter-thread communication will generally have to move data through the expensive parts of the memory hierarchy). Your goal in either case will be to architect your solution to minimize the overhead that you are dealing with.

Also, you're starting to hit physics issues once you want to do shared memory past maybe 16 cores or so. Thermal issues, obviously, but also memory bandwidth and such. And the solutions to these can have an economic impact where choosing a more distributed approach can simply be cheaper. When you're dealing with thousands of concurrent processes (as some Erlang applications do), then a pure shared memory solution is usually right out (though various hybrid approaches can still have advantages over a pure message passing system).

Message passing in Erlang will be a fair amount more expensive - Erlang and C++ have far, far more differences in terms of performance than just message passing vs shared memory.

You're better off comparing C++ and Pony. At that point, a message enqueue is 3 atomic instructions, not too bad. The benefit is trivial concurrency.

A: Yes.

B: Doesn't matter since you're not resource constrained on the backend.