I read Joe Armstrong’s ‘Programming Erlang’, and the ‘n times faster in n core machine’ theory. The efficient way to multicore programming in Erlang is to use lots of processes (threads).
I’m a C++ programmer, so I am curious about the difference between making lots of threads in C++ and making lots of processes in Erlang. I understand dealing with threads in C/C++ is not that easy. Also I know locking/unlocking makes the system slow down. But it is not impossible, right?
So.. why is Erlang a muticore friendly language? Is it just because it’s easy to program?
I’m making an online game server for a MMORPG, that’s why I’m interested in Erlang as an alternative server language.
(I already read this question but I think it’s not the question I’m looking for.)
No, it’s not impossible, but Erlang does make it much easier. The key is not sharing state among the processes. Erlang achieves this by virtue of it being a functional language. The function should have no side effects nor should it access any variable state (other than the arguments passed on the stack). With these properties, computation of any function in the system can be moved off to another processor with a separate memory space and Erlang will do this for you. Erlang only needs to replicate the arguments to the function and the results between the memory spaces (note: this would not be suitable for all kinds of applications…a function that needed to operate on a very large body of input state might present performance issues when replicating that state).
A naive use of threads in a C++ application might have different processors (in a multi-core system) trying to access the same shared memory at the same time. The system then has to do a lot of work to make sure the local caches associated with each core remain consistent. This is where you can suffer huge performance hits. We have an application at work that degrades in performance when you have more than a couple cores for this very reason. In fact, I’d go so far as to say you’d be better off to design your applications to only use threads where you need to do asynchronous I/O, but where you need to have processes doing real work and not blocked for I/O, use full processes. By using full processes, you guarantee that each process has it’s own memory space and no two threads will use the same memory at the same time (of course, you then need to come up with a good means of communicating between those processes). With a system like this and a discipline around managing state and distributing processing, you could achieve similar results to what Erlang provides, but you have to do a lot of infrastructure stuff that Erlang already does for you.