Upcoming article in Dr. Dobbs'

[Vlad Dumitrescu]

Hi,

----- Original Message ----- 
From: "James Hague" <james@REDACTED>
> But is Erlang a solution to the problem he talks about?  Let's say
> that in a couple of years the standard desktop box ships with CPUs
> containing four to eight processors on one chip.  Current Erlang
> implementations won't make use of all those processors, as the
> emulator does the bulk of its work in one thread.

Good point. In theory, I don't see any huge problem to implement a 
multithreaded runtime. See below.

> You could fire up
> eight emulators at once and go distributed from the start, but then
> you still need to manually do some kind of load balancing, to make
> sure that the work is truly split up among the eight.

The equivalent of one node per thread is probably the easiest to do. 
However, I don't see how the load balancing (for example) could be achieved 
in a significantly better way than for running the nodes in separate 
processes.

If using non-shared heap, is there any big difference between a threaded 
runtime and separate nodes? The only other shared objects are drivers, I 
think.

If using a shared heap, then the way to go would be to split heap management 
from the virtual machine, but synchronizing the stuff might require 
rewriting the runtime in Erlang! Would probably make a nice PhD thesis :-)

> I'd love to see a way of having Erlang automatically make use of
> multiple CPUs on the same box.  That would provide *huge* wins.

That might. Or might not. I'm not sure. I think the load balancing might 
provide the biggest wins, and that one could be used just as well between 
regular nodes.

regards,
Vlad