ErlCee++

[Shawn Pearce]

Luke Gorrie <luke@REDACTED> wrote:
> Shawn Pearce <spearce@REDACTED> writes:
> 
> > The downside here is that POSIX threads and UNIX processes cost a lot
> > more of memory resources and context switch latencies than an Erlang
> > process costs.
> 
> "I must program as inefficiently as possible."

Ahhhh.... does that mean the human developer being inefficient by
reinventing the wheel, or does it mean the system being horribly
inefficient?  :)

My biggest concern is if Linux 2.6 takes 2 usec to context switch;
and we're only looking at having ~200 kernel processes; the latency
could still be pretty high between them.  Especially if there are some
CPU bound processes that get a full 1 ms between an event occuring
in one process and it sending a message to another.  Erlang also
has this type of latency, but I don't seem to see it affect it as much;
but perhaps I'm being nitpicky here?

> I wonder what the real CPU/memory costs would be of using Unix
> processes instead of Erlang ones? I've heard rumour that Linux/x86 is
> making processes and threads lighter-weight all the time.
> 
> I find it interesting that in our distributed control system at work
> we don't have so terribly many processes:
> 
>   (isd@REDACTED)1> length(processes()).
>   209
> 
> Compare that with Linux on my laptop:
> 
>   $ ps ax | wc -l
>       142
> 
> Perhaps OS processes are in fact lightweight enough for more than we
> tend to assume? Not every program is like Yaws :-)

They are getting pretty darn light in Linux.  There's more static
overhead per process than I'd like; but compared to not having them
at all its well worth that price.  As you said today,
"Memory is cheap".

> I'd really like to see an Erlang-like runtime system built on Unix
> processes. How far towards the Erlang programming style could it be
> pushed? Wouldn't it be fun to be able to write "Erlang" processes in
> any language and mix 'em all together?

Ah yes, I think this mix'n'match was around #5 of the top ten
reasons to use Erlang.  Its easy to mix'n'match message passing
applications when the message protocol is well defined (or can be
well defined).  It also forces one to design the system interactions
better up front (reason #2 or #3).

--
Shawn.