performance penalty of message passing as opposed to shared data

Question

There is a lot of buzz these days about not using locks and using Message passing approaches like Erlang. Or about using immutable datastructures like in Functional programming

Answer 1

There are some implicit assumption in your questions - you assume that all the data can fit on one machine and that the application is intrinsically localised to one place.

What happens if the application is so large it cannot fit on one machine? What happens if the application outgrows one machine?

You don't want to have one way to program an application if it fits on one machine and a completely different way of programming it as soon as it outgrows one machine.

What happens if you want make a fault-tolerant application? To make something fault-tolerant you need at least two physically separated machines and no sharing. When you talk about sharing and data bases you omit to mention that things like mySQL cluster achieve fault-tolerence precisely by maintaining synchronised copies of the data in physically separated machines - there is a lot of message passing and copying that you don't see on the surface - Erlang just exposes this.

The way you program should not suddenly change to accommodate fault-tolerance and scalability.

Erlang was designed primarily for building fault-tolerant applications.

Shared data on a multi-core has it's own set of problems - when you access shared data you need to acquire a lock - if you use a global lock (the easiest approach) you can end up stopping all the cores while you access the shared data. Shared data access on a multicore can be problematic due to caching problems, if the cores have local data caches then accessing "far away" data (in some other processors cache) can be very expensive.

Many problems are intrinsically distributed and the data is never available in one place at the same time so - these kind of problems fit well with the Erlang way of thinking.

In a distributed setting "guaranteeing message delivery" is impossible - the destination machine might have crashed. Erlang cannot thus guarantee message delivery - it takes a different approach - the system will tell you if it failed to deliver a message (but only if you have used the link mechanism) - then you can write you own custom error recovery.)

For pure number crunching Erlang is not appropriate - but in a hybrid system Erlang is good at managing how computations get distributed to available processors, so we see a lot of systems where Erlang manages the distribution and fault-tolerent aspects of the problem, but the problem itself is solved in a different language.

and other languages are used