What makes Erlang suitable for soft real-time applications? [closed]

Answer 1

Real-time code can dynamically allocate memory, it just has to be more careful about it.

In real hard real-time the dynamic memory handling will just become another of those factors which have to be taken into account when working-out whether the system can do what it has to in the time allotted. Hard is worst-case.

In soft real-time it is usually enough to check that the dynamic memory handling will not take to too much time and result in too long pauses. Soft is average case.

The erlang system just quite a good job for soft real-time apps, the dynamic memory handling is reasonably efficient and normally does not cause any noticeable pauses. And while it will probably introduce some non-determinism this in itself shouldn't you any problems. I mean that if time is important to you then you should anyway be timing the app, for example so that the audio samples "arrive" on time.

It is a completely different question if erlang is the right language for your app. One thing that has not been really optimised is numeric calculations. Erlang can of course do them but it has nowhere the speed of low-level languages. They have generally not been critical to the types of apps for which erlang has been used. But then again there is Wings 3D, an open source subdivision modeler inspired by Nendo and Mirai from Izware, which is written in erlang. So all is not hopeless. :-)

Really the only way to find out is to write a small test and try it out. Another question is what James mentioned, which type of language would you prefer to use?

Answer 2

In end Chap 1, Cesarini / Thompson book, which is excellent, it talks about code SLOC difference vs. a C++ telecomm app: 85% of the C++ code is defensive coding, memory management, high-level communications, which are pretty much unnecessary in functionally comparable erlang code.

Take a look if you're in a bookstore or can borrow from somebody.

also read about research into hard realtime apps

http://lambda-the-ultimate.org/node/2954

http://www.scribd.com/doc/415282/05nicosi

Answer 3

Since Erlang was created by Ericcson Communications for use in telecommunication, fast and scalable is an important consideration.

You may want to look at this article regarding trying to get Erlang ready for hard real-time applications, to see what problems they need to overcome for that. http://lambda-the-ultimate.org/node/2954

You may find that some of the issues that are still there may be a show-stopper for your application also.

You may also find this of interest, as FP will be different than OOP, so some of the problems you encounter in OOP will be different in the FP domain. http://blog.ribomation.com/2009/06/28/the-ups-and-downs-of-erlang/

In functional programming, once you set a variable it is immutable, generally, so you don't create lots of new objects. Through recursion you will find that you will have fewer variables, so the garbage collection becomes more important, which may help resolve the memory issues you are having.

But, you would need to see if your problem will work well in FP, as it is not the best language for all situations.

Answer 4

I really don't agree with the question. It's asking for too much.

"...This would require dynamic memory allocation. How would Erlang help me make sure that this allocation does not delay my audio computation?".

It's unlikely that tools exist (in Erlang or any other language) to give you this assurance in advance.

A method that has always been used is timing tests or benchmarks.

If you want to prove that your code will not delay your audio computation, you will probable need to construct this proof yourself. But steps in the proof might rely on previous timing tests.