Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Fri, 24 Feb 2006 22:13:04 +0100

On Friday 24 February 2006 20:44, Kay-Uwe Kasemir wrote:
> You can't directly compare that to the exception::what()
> or event queue,
> because he's talking about an environment where
> each message (a new CA monitor, an error message, ...)
> is passed between processes which can't share anything.

Yes. OTOH, since Erlang is a functional language, all data is 
'constant' (immutable) anyway, so sharing stuff between threads would 
be possible, in principle. They don't do it, because they want GC to be 
per-thread, not global, in order to reduce GC induced latency. (Note: 
Erlang was not designed for hard real-time tasks; there /is/ GC latency 
and it is not predictable in general. In practice, however, it is so 
low, that you can neglect it for almost all applications.)

> So the database posting a monitor and channel access queuing it,
> or the exception thrower and the catcher,
> would all be different processes,

If EPICS was implemented in Erlang, /each record/ would get it's own 
thread. (And CA would disappear because message passing in Erlang is 
already network capable. Well, even records would probably disappear, 
at least as regards data storage, since Erlang already comes with a 
(replicable, distributed) run-time database. We would still need to 
program record /processing/. Note, I mention all this only for 
illustration, it is all theoretical, not a proposal in any way.)

> pointers wouldn't work between them.
> He also envisions some global garbage collector.

He isn't 'envisioning' anything. Erlang is GC'd language and has been 
sucessfully used for production control systems with extreme 
reliability and scalability requirements. (telephone switches with < 3 
minutes/year downtime, etc..).

> I think java is somewhere in between:
> You can still share pointers between threads,
> but only pointers to objects, not types like 'double'.
> and you have garbage collection.
> That's already easier to use than C/C++,
> and you don't enter yet another string-related discussion
> with every API that anybody suggests for anything.
>
> But at the same time, java is already slower than C/C++,
> and I wonder about the performance of Erlang.

Much better than Java, I bet. Not as fast as C or C++. Particularly, 
Erlang does /not/ specialize in number-crunching.

However, its built-in concurrency and distribution support is extremely 
efficient and scalable. This can easily tip the balance for code that 
is heavily multi-threaded and/or distributed. See for instance 
http://www.sics.se/~joe/apachevsyaws.html. BTW, Erlang is reported to 
have been benchmarked with 20 million (!) processes on a single machine 
(the latest UltraSPARC with lots of memory, IIRC).

Of course, Erlang's runtime system is written in (fine-tuned, 
hand-optimized) C...

Cheers,
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System