tags:

views:

144

answers:

2

I was searching about process model of Erlang over internet and found out some graphs alt text slides 3-4 in one of the talk given by Joe Armstrong. They shows a lot of difference between process creation and message passing time between Erlang , java and C#. Can anybody tell me the reason behind such big difference?

+3  A: 

Erlang processes are very light weight. An implementation does not even need to allocate an OS thread to an Erlang process. This has to do with the functional nature of Erlang.

jdv
Not really related to Erlang being a functional language at all. Any language with cheap processes and message passing would do. (Not that there are any other languages with Erlang-like processes...)
Daniel Luna
Actually it's very related to Erlang being a functional language in that the the functional nature of single-assignment variables removes much of the burden of process isolation because there can be no shared update or access contention to worry about. Add message copying instead of referencing and you've got a recipe for really lightweight processes.
Alan
@Alan: yeah that's what I had in mind, thanks for writing it down for me. :)
jdv
+6  A: 

In Erlang, processes are not real processes. They are light structures handled by the language. Message passing is also handled by the language, using shared memory when possible.

In the other hand, other languages are using real threads / processes since they don't have built-in light structures like this. Therefore, these structure are a bit heavier, are using thread primitives to communicate (slower).

I don't know about your graph, but I guess it shows that Erlang's processes are better. It's done comparing things that are inherently different, however it show that Erlang rocks to model standalone objects communicating using messages (things you cannot really do in other languages).

Scharron
I wouldn't say that it uses shared memory, since data is (almost) always copied between processes' heaps. Though still everything happens inside one OS process.
gleber
I think Scharron meant that while, conceptually, nothing's shared, it's possible for the VM to share data by passing pointers around rather than copying the data, as an optimisation.
Frank Shearar