I am not too sure that an is_float() guard will yield a performance increase in the BEAM interpreter. It will give an increase with HiPE though I am sure. As per strings and memory consumption: Yes, you can use binaries or even better: iolists, but I think, then, that the string type has to go. A good (immutable) string library based upon binaries in OTP would be nice.
Concurrency and parallelism: No, they are not the same. A concurrent problem is one where you want to cope with concurrent activities: web servers, phone switch exchanges, routers, etc. A parallel problem is one where you worry about how to split the problem across multiple CPUs/Nodes so that you utilize as many resources as possible while achieving the best speedup possible.
The latter is usually number crunching on big clusters of several hundred machines -- or number crunching on a grid of computers loosely spread all over the world. The first is about coming up with a nice model for computation that makes you model the problem in a logical and straightforward way.
Erlang has a very nice concurrency-model. Together with the rock-solid and stable VM you have a very good outset for solving concurrent problems. But -- you can implement concurrency well on a single CPU, the key point is that you have a nice model in which to work when trying to explain the problem to the computer.
In a parallel problem, it is crucial how you split the problem up. Some problems have subproblems independent of each other. These are called 'embarrassingly parallel' problems. All of these are map-reducible. But how about a problem which is not? Numerical solving of differential equations via successive over-relaxation is a classical problem because each subpart needs to communicate its findings to neighboring subparts. You are worrying about the speedup when adding more CPUs or by Gustafsson: keeping the time-frame constant and adding more CPUs - how much bigger a problem you can solve.
Erlang, being about 30 times slower than C on numerical computation, needs at least 30 times the speedup to compete. Depending on the problem, that can be achieved with, say 32 CPUs, or perhaps not at all (if the problem has no inherent parallelism), where the C program only uses a single CPU. That is the gap Erlang is currently competing with. If you take the de-facto standard, MPI, and use that on C, you pay a lot of development time for a message passing interface which even allow for asynchronous messaging (crucial for hiding the latency of computation).
Concurrency and parallelism: No, they are not the same. A concurrent problem is one where you want to cope with concurrent activities: web servers, phone switch exchanges, routers, etc. A parallel problem is one where you worry about how to split the problem across multiple CPUs/Nodes so that you utilize as many resources as possible while achieving the best speedup possible.
The latter is usually number crunching on big clusters of several hundred machines -- or number crunching on a grid of computers loosely spread all over the world. The first is about coming up with a nice model for computation that makes you model the problem in a logical and straightforward way.
Erlang has a very nice concurrency-model. Together with the rock-solid and stable VM you have a very good outset for solving concurrent problems. But -- you can implement concurrency well on a single CPU, the key point is that you have a nice model in which to work when trying to explain the problem to the computer.
In a parallel problem, it is crucial how you split the problem up. Some problems have subproblems independent of each other. These are called 'embarrassingly parallel' problems. All of these are map-reducible. But how about a problem which is not? Numerical solving of differential equations via successive over-relaxation is a classical problem because each subpart needs to communicate its findings to neighboring subparts. You are worrying about the speedup when adding more CPUs or by Gustafsson: keeping the time-frame constant and adding more CPUs - how much bigger a problem you can solve.
Erlang, being about 30 times slower than C on numerical computation, needs at least 30 times the speedup to compete. Depending on the problem, that can be achieved with, say 32 CPUs, or perhaps not at all (if the problem has no inherent parallelism), where the C program only uses a single CPU. That is the gap Erlang is currently competing with. If you take the de-facto standard, MPI, and use that on C, you pay a lot of development time for a message passing interface which even allow for asynchronous messaging (crucial for hiding the latency of computation).
I hope this makes the difference clear.