Realtime capabilities?

[Peter Hansen]

Peter Hansen wrote:
> 
> Aahz Maruch wrote:
> >
> > In article <9o8033$mhf$04$1 at news.t-online.com>, Ben  <ben at xyz.net> wrote:
> > >
> > >some of you have probably heard (or even used) Erlang (www.erlang.org) ---
> > >a functional programming language which is executed by a virtual machine.
> > >One interesting property of this VM is guaranteed soft realtime execution
> > >of the Erlang processes.
> > >
> > >My question is whether it is possible to add (soft) realtime capabilities
> > >to the Python VM with reasonable effort? I'm just curious and not being an
> > >expert of any of the existing Python implementations I thought some of you
> > >might have a better understanding of this issue and can comment on this?
> 
> We might be better guided by the terminology as defined by those
> who actually _do_ realtime work, as opposed to whatever it is
> these Erlang people are (those who just write about it?).

Before I get too badly flamed for this one, I'll admit I'd overlooked
_who_ "these Erlang people" actually were, and had I realized they
were Ericsson I would have investigated further to see whether
they were really making statements such as "the VM guarantees soft
realtime execution", which out of context is meaningless to someone 
doing realtime work.

Paul Foley emailed me (maybe it will come to the list, too):

> FWIW, "these Erlang people" are primarily Ericsson, a large
> manufacturer of telephony equipment (driving which is the purpose they
> created Erlang in the first place, though it's apparently quite widely
> used outside Ericsson nowadays, too).  [It's designed for, and running
> in, real life hard realtime high availability applications.  So no,
> they don't just write about it]

Thanks Paul :-).  After looking at their FAQ, however, I see they
only talk about providing soft realtime support, not hard realtime.
Since they don't explicitly say there is any hard realtime guarantee,
I wonder whether the applications you refer to are not just the 
telecomm apps they talk about below, which are "soft".  I may
have overlooked other information.  They have these excellent 
definitions in the FAQ (so they clearly know something about the
issues):

"""
 A hard realtime system is one which can guarantee that a certain 
 action will always be carried out in less than a certain time. Many 
 simple embedded systems can make hard realtime guarantees, e.g. it 
 is possible to guarantee that a particular interrupt service routine 
 on a Z80 CPU will never take more than 34us. It gets progressively 
 harder to make such guarantees for more complex systems. 

 Many telecomms systems have less strict requirements, for instance 
 they might require a statistical guarantee along the lines of "a 
 database lookup takes less than 20ms in 97% of cases". Soft realtime 
 systems, such as Erlang, let you make that sort of guarantee. 
"""

Note the last sentence.  One can guarantee a particular response
characteristic, but if it leaves 3% of the cases open to question
it is not deterministic, therefore not "hard" realtime.  

(Note, for those new to realtime, that the absolute values are not
relevant.  The above examples code just as easily have been "34ms"
for the hard realtime case, and "20us in 97% of cases" for the
soft realtime case.  All that matters between hard and soft
is whether the response is deterministic.)

Peter Hansen wrote:

> Python is definitely suitable for "soft" realtime applications,
> by any definition of "soft" the realtime people generally accept.
> I use it in several complex "soft" realtime applications.

Judging by the FAQ, it appears that to some extent they believe
Erlang's suitability for soft realtime revolves around the 
lightweight-ness of the threads, providing fast switching and 
therefore lower latency, and the fact that garbage collection is 
on a per-process basis.  Neither of these issues is in any way 
involved in determining whether something is "soft" or "hard" 
realtime, but it can make a language more or less suitable _in 
a particular application_, such as Ericsson's.

Python can be restricted to use only reference counting, which is 
more deterministic than garbage collection inherently.  Note that
Erlang's implementation is unsuitable for their claims anyway
(and even their "per-process" garbage collection halts other
processes while running!).

"""
 The current GC is a "stop the world" generational mark-sweep 
 collector. Each Erlang process has its own heap and these are 
 collected individually, so although every process is stopped 
 while GC happens for one processes, this stop time is expected 
 to be short because each process is expected to have a small heap. 
"""

The first item they mention in the FAQ, however, is "Language features 
which make it hard(er) for programmers to roughly estimate performance 
were never added to Erlang. For instance, Erlang doesn't have lazy 
evaluation."  This statement is important to the issue.  In fact,
it's the only statement that is important.  There are probably features 
in Python which make it difficult to estimate performance, even roughly,
so unless you are willing to exclude those features, it might be 
fair to say Erlang is "more suitable" than Python in this regard,
so long as you realize "more suitable" means simply "more amenable
to analysis and estimation".

Peter Hansen wrote:

> No language is suitable for hard realtime without a hard
> realtime operating system underlying it (unless you dispense with
> operating systems entirely, as in an embedded system).  Either
> Python or Erlang could probably be used for hard realtime work with
> adequate analysis and measurement, since all you really need to do
> is guarantee the maximum duration of each of the operations
> performed _in the actual application_.  If there are no operations
> which are used in the program which have unbounded execution times,
> then it is possible to guarantee the response time to an external
> stimulus, meaning you can call it "hard" realtime.

Revisiting this statement after learning just enough more about
Erlang to be dangerous, I'll venture way out on a limb and say that 
it seems that *Python* is more suitable for hard realtime work
than Erlang, but that Erlang is more suitable for most types
of work which people refer to as "soft" realtime.

Usually people talking about "soft" realtime think that 
short context switch times are somehow important.  What they
really mean is that for *their* application, short context
switch times are very important.  Since Erlang was obviously
designed specifically to provide low latency (other than
that danged garbage collector), it probably suits the
needs of some "soft" realtime applications better than Python
does.  Stackless Python, with which I have no experience, 
probably works almost as well in this regard.

And all any of this says is that without defining the 
context (e.g. telecomm apps which needs 20ms response
97% of the time), generalizations about which language is
"better" than the other are misleading or meaningless.

-- 
----------------------
Peter Hansen, P.Eng.
peter at engcorp.com