4 ms·

Question for those of you who are game programmers. Is the message passing of erlang slower than shared memory threads in c++?

physguy1123 10y ago
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.
staticassertion 10y ago
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.
diamondlovesyou 10y ago
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.
hderms 10y ago
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.
- staticassertion 10y ago
  What concurrency patterns have you found yourself unable to express using actors?
- qaq 10y ago
  Well short answer long term it's the only viable model you are not going to use locking and STW gc on 500+ core system with few TBs of RAM.
  - ianopolous 10y ago
    Lock based concurrency is perfectly fine on 800 core systems with a pauseless gc and many TiB heaps. See Azul for an example using the JVM.
- toast0 10y ago
  Memory leak isn't quite the right word for what I think you're referring to: processes that most forward binaries without generating enough garbage on their own heap did not trigger garbage collection, leading to too much memory being used. This behavior is better in recent releases (otp 19), the space used by binaries is added to the per process accounting so that it can trigger garbage collection. I agree, if you don't fit into the actor pattern, erlang is probably not a great choice, although the bit syntax is pretty nice, too. Sometimes you can leverage erlang for distribution and supervision and drive the c code; but sometimes it's just not a good fit.
- pmarreck 10y ago
  I second the question of wondering what sort of concurrency is not well-serviced by the actor model? (especially considering you have zero locking to worry about)
vvanders 10y ago
A: Yes. B: Doesn't matter since you're not resource constrained on the backend.
rbehrends 10y ago
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).

physguy1123 10y ago

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.

staticassertion 10y ago

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.

diamondlovesyou 10y ago

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.

hderms 10y ago

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.

staticassertion 10y ago
What concurrency patterns have you found yourself unable to express using actors?
qaq 10y ago
Well short answer long term it's the only viable model you are not going to use locking and STW gc on 500+ core system with few TBs of RAM.
- ianopolous 10y ago
  Lock based concurrency is perfectly fine on 800 core systems with a pauseless gc and many TiB heaps. See Azul for an example using the JVM.
toast0 10y ago
Memory leak isn't quite the right word for what I think you're referring to: processes that most forward binaries without generating enough garbage on their own heap did not trigger garbage collection, leading to too much memory being used. This behavior is better in recent releases (otp 19), the space used by binaries is added to the per process accounting so that it can trigger garbage collection. I agree, if you don't fit into the actor pattern, erlang is probably not a great choice, although the bit syntax is pretty nice, too. Sometimes you can leverage erlang for distribution and supervision and drive the c code; but sometimes it's just not a good fit.
pmarreck 10y ago
I second the question of wondering what sort of concurrency is not well-serviced by the actor model? (especially considering you have zero locking to worry about)

vvanders 10y ago

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

rbehrends 10y ago

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).