Upcoming article in Dr. Dobbs'
Joe Armstrong (AL/EAB)
Mon Jan 10 10:47:42 CET 2005
Yes Erlang *is* the answer - but what's the problem?
How are we going to make use of truly parallel CPU cores?
When Intel makes 4 (6 8 10 ...) processors on a chip will we
get speed ups of 4 (6 8 10...)?
Chip makers can go two ways: 1) make more fancy CPU's or 2) blow multiple
CPUs onto the same chip. The 1) alternative is unlikely since the designs are already horrendously complex - 2) is a much better alternative.
Also, you have to get data in and out of a chip, I/O occurs at the edges of a chip
but processing in the middle - so CPU power grows quadratically, and I/O only linearly.
Thus the best architecture, is a chip with I/O processors on the edges and multi CPUs in the middle (the cluster on a chip).
These chips are one the way - should be here by 2006/7
- It will be a nightmare porting threads based S/W onto true
multi-CPUs - true concurrency (in the CPUs) will uncover loads of new errors that do
not occur using pseudo-concurrency - the only way to program these boxes will be
with concurrency based on pure (copying) message passing.
Concurrency models based on sharing will totally screw up -
Erlang is the only language I know of that is well placed to program multiCPUs
all other approaches use some form sharing and or locking (which as I have said many
times before - is the root of all evil)
> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> Sent: den 8 januari 2005 16:31
> To: erlang-questions@REDACTED
> Subject: Re: Upcoming article in Dr. Dobbs'
> > "The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in
> > Software
> > The biggest sea change in software development since the OO
> > is knocking at the door, and its name is Concurrency."
> 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. 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. And goes
> against the grain of the work toward a shared-heap architecture, too.
> 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.
More information about the erlang-questions