[erlang-questions] SMP Paper

Dave Smith dizzyd@REDACTED
Tue Jun 2 19:25:38 CEST 2009


For all your SMP questions, I would note that there is no "Right
Configuration" -- I find the best approach is to design a solution for
correctness/obviousness first and then start attacking low-level
details such as the efficiency of the SMP stuff in Erlang or in
conjunction with VMWare... once it's determined that you actually have
concurrency issues.

In the time I've been building Erlang apps professionally (only ~3.5
years now) I've found that Erlang is often far more performant than I
originally imagined. I.e. the most straightforward/Erlangy solution to
a given problem is usually plenty fast. The Erlang team has done a
spectacular job in making the VM fast and stable. Most of my
development time in Erlang is not spent thinking about speed so much
as correctness. I.e. what happens when process X crashes? What other
processes need to know about and what should they do..etc.

One thing you should be aware of wrt to speed in Erlang is that
numeric processing is not exactly its forte -- if you want to do heavy
number crunching (crypto, vector math, etc) you might be better off
using Erlang as a coordinator for invoking external processes. Then
you get the advantages of supervising, independent processes and
transparent distribution with speed. But again, you will probably be
better off with starting simple with a native Erlang implementation
and then profiling it to find bottlenecks.

<rambling>

On reflection it's not entirely clear to me why developers focus so
much on speed and so little on uptime. Yes, speed is important, but
for most applications I would argue that not crashing should be the
first priority. Crashing (and the recovery thereof) can be quite
expensive and can have a far more detrimental effect on user
experience than speed. Obviously there are exceptions to all this
rambling, but I think we would all be well served by focusing on
writing software that NEVER crashes and then attacking the speed
problem once we're good at the first task. Erlang's partial failure
and supervisory mentality is well suited for this task.... :)

D.


More information about the erlang-questions mailing list