General questions about the power of Erlang

[Ulf Wiger]

On Mon, 11 Dec 2000, Karel Van Oudheusden wrote:

>I am hesitating on using Erlang (for designing and implementing
>multimedia client server Internet applications).
>Would somebody please answer (some of) the following questions for me:

Of course you have to look at the specifics of your application, but
the words "multimedia client server Internet applications" sure ring
like Erlang to me.  (:


>1)  If I look at the evolution from Java to Java for real-time (RT),
>the programmer will be able to specifiy physical memory desires in
>the Java for RT API.  The reason for this is because the Java for RT
>API will permit the programmer to use "Java physical memory
>objects".  This is a new class added to the Java RT API.
>
>I am wandering whether I am able to do physical memory management in
>Erlang too?

Personally, I feel that Java for real-time is messing with a lot of
stuff that it could leave alone if the underlying model were more
sound... However, I can see that some applications have a need for
specific memory management. You won't see that in Erlang, I wager, but
I would suggest that you write some prototypes before you decide that
Erlang isn't up to the job. As Maurice mentioned, memory management in
Erlang has been vastly better than Java's memory management.

Quite often, you can find that Erlang makes some things very easy that
are (sometimes extremely) hard in other languages. If you find a way
to mix Erlang and e.g. C code, you may arrive at a very stable and
efficient platform.


>If I am not able to specify physical (or even virtual) memory management
>constraints in Erlang, I still assume that I can change some
>functionality behind the scenes to obtain the same effect.

There are a couple of things to consider:

- If you work with images, the logical way to deal with them in Erlang 
  is with the "binary" datatype. Binaries are allocated once, as 
  read-only BLOBs, and pointers are passed around instead of passing
  the whole object. When deriving new binaries from old ones, Erlang
  tries to minimize copying.

- One can always write a linked-in driver in C, which handles, e.g., 
  a bitmap. Using the port_control function, Erlang code can call the
  C code synchronously.


>2)  I have worked with Ada95 previously.  I read that Erlang was
>developed with Ada and the functional paradigm as the main sources of
>inspiration.  This is great, however, my experience with Ada95 is that
>it behaves differently on different platforms even though it is not
>supposed to do this.  As a matter of fact, it is well known by know that
>the Ada specifications are not supported to a full extent on all
>platforms that can run Ada95.
>
>I was wandering whether Erlang does behave correctly on for instance
>Windows and if so, does it behave in the same manner as on Linux?

I can't really speak for Ada, except to say that you are correct in
that Ada was one of the languages studied by the Ericsson Computer
Science Lab in the experiments that led up to Erlang. One conclusion
from the Ada experiment was that message passing had to be
asynchronous.

Erlang works the same on all OSes in the sense that the semantics are
exactly the same. For most Erlang applications, the virtual machine
offers the familiar environment with lightweight preemptive
multitasking. The OS will make itself known occasionally, by
interrupting the virtual machine. This usually affects the Erlang
processes in the same way as if they had to wait for one or two other
Erlang processes.

Some operating systems exhibit blocking behaviour once in a while.
I've seen Solaris block for up to 10 minutes when accessing the file
system through a ClearCase client. To avoid this, you can try to
reduce the number of components that can cause the system to block, or
run a real-time operating system. Erlang, for example, runs well on
VxWorks, a real-time OS, which allows you to set real-time priority on
the Erlang virtual machine. Still Erlang processes will not notice
this except for the reduced risk that bad things (blocking) will
happen.


>It is for me hard to believe that Erlang actually works well on Windows
>platforms since we are talking here about (soft) real-time
>applications.  Or am I missing something here?

On Windows NT, you can give the Erlang VM higher priority. On Windows
98, you can pray that they whole system won't crash. If you program in
Erlang, you can put two PCs on the same network and make your
application distributed with little effort. Then, you can load share
and protect your application through redundancy.

If you want realtime performance on Windows, check out the VenturCom
RTX kernel
(http://www.venturcom.com/products/vci_products/rtx/rtx_index.html)
Erlang offers no special support for this, however.


>3)  I read in the FAQ that application types, such as image processing
>and signal processing, are not meant to be implemented in Erlang.  (They
>would perform badly if they were implemented in Erlang.)

Erlang was designed to be good at building telecom applications. It
has been found good at several other type of applications as well,
Image processing is not common in telecom or datacom systems (the type
of applications built by Ericsson.)

It's quite possible that Erlang will become radically better at such
applications, as e.g. compilers improve. The amount of copying that
today makes certain applications behave very poorly might be reduced
with smart use of destructive update of data structures behind the
scenes, but now we're talking R8 or later.


>I am wandering if research is being done on defining a new "Erlang
>approach" for these types of applications.  So instead of concurrent,
>distributed and hot code loadable applications, a new kind of Erlang
>semantics could be developed for data dominated, real-time, multimedia
>processing applications.

There is always research. (:

One good thing about Erlang is that the released versions are of the
highest quality. Sometimes, one would perhaps like more experimental
versions to play with.

There are Erlang implementations that take a different approach on
performance. You could look at HIPE 
(http://www.csd.uu.se/projects/hipe/), which seems to be the only
accessible alternative (the ETOS link doesn't work).

/Uffe
-- 
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB