johndonsp

You text and drive at the same time? Isn't that illegal in most countries and states?

I completely agree with you about fault-tolerance. However Erlang, CSP, actors and message passing are heralded as the key to parallelism. The Erlang book still promises n-times speedup for n-cores, with not enough of a caveat.

That's the limitation of Erlang, right there. They get in line, creating a bottleneck. You could have 10,000 Erlang processes, but they all wait in line for this one process to service them.

If you use transactional memory with threads and mutable state, then all your booking processes can access the board state in parallel with ACI properties. Obviously, parallelism is still limited, as it always it, but as long as your booking processes are accessing different parts of the seat data structure, they can run in parallel. If they try to access the same part of the structure at the same time, all but one will be rolled back, but that one still gets through. Hopefully, they access different parts of the structure and sail through.

Your suggested Erlang program has no parallelism in it at all (for the isolated part of the seat booking of course), and will not scale to 2 cores, let alone the 64 cores I have in my machines at work.

No, the parallelism in that algorithm is fundamentally limited. That bottleneck is not going away, and was an example of where neither Erlang nor any other model of parallelism will help you.

Do you have any good ideas about how I can solve the seat booking example using Erlang's model of parallelism? There is a block of seats. I want to be able to handle seat bookings in parallel. The seats that people might want to book could be in large groups - as large as all of the seats.

I wonder if those apps run n-times faster on n-cores. I think probably not, due to inherent limitations in the parallelism available in them, but perhaps I should do a study to verify that. Erlang claiming n-times faster on n-cores is snake oil. First of all, not all problems have n-times parallelism in them!

Message passing is fantastic... when you can decompose your problem into lots of small, independent jobs, like a web server. However not many algorithms are like that. If you can't decompose your problem into small independent jobs then you will be left with some kind of shared job. For example, an airline seat booking system, where at some point you need to modify a shared set of seat states (no, you can't divide the seat state up, because then you can't take massive bookings if needed). Another example is sorting algorithms. If you divide and conquer, at some point you need to combine results.

In Erlang, the normal way to do this is to have a single actor handled that shared job. That then becomes a huge bottleneck, and with more cores it gets to be more and more of a bottleneck. This is Amdahl's law. This is where Erlang breaks. In a language with shared state (that includes Haskell or ML with mutable references) I can use very fine grained locks, or perhaps transactional memory, over this shared part of the problem, and continue to scale beyond what Erlang was capable of. Probably not near n-times for n cores, but much closer than what Erlang would allow.

Erlang's message passing creates bottlenecks! And then there's no way out. In shared state you can be nice and message passing, but then also have the power to use very fine grained locks or TM to break down those bottlenecks.