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?
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.
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.
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.
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.
发布评论
评论（4）
实时代码可以动态分配内存，只是必须更加小心。
在真正的硬实时中，动态内存处理将成为在确定系统是否可以在分配的时间内完成其必须完成的任务时必须考虑的另一个因素。困难是最坏的情况。
在软实时中，通常足以检查动态内存处理不会花费太多时间并导致太长的暂停。软是平均情况。
erlang 系统对于软实时应用程序来说非常出色，动态内存处理相当高效，并且通常不会导致任何明显的暂停。虽然它可能会引入一些非确定性，但这本身不应该有任何问题。我的意思是，如果时间对您来说很重要，那么您无论如何都应该为应用程序计时，例如，以便音频样本按时“到达”。
erlang 是否适合您的应用程序语言是一个完全不同的问题。尚未真正优化的一件事是数值计算。 Erlang 当然可以做到这些，但它的速度远不及低级语言。它们通常对于使用 erlang 的应用程序类型并不重要。不过，还有 Wings 3D，这是一款开源细分建模器，其灵感来自 Izware 的 Nendo 和 Mirai，是用 erlang 编写的。所以一切并非毫无希望。 :-)
真正找出答案的唯一方法是编写一个小测试并尝试一下。另一个问题是詹姆斯提到的，你更喜欢使用哪种类型的语言？
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?
由于 Erlang 是由 Ericcson Communications 创建用于电信领域，因此快速和可扩展性是一个重要的考虑因素。
您可能想查看这篇有关尝试让 Erlang 为硬实时应用程序做好准备的文章，看看他们需要克服哪些问题。
http://lambda-the-ultimate.org/node/2954
您可能会发现仍然存在的一些问题也可能会阻碍您的应用程序。
您可能还会对此感兴趣，因为 FP 与 OOP 不同，因此您在 OOP 中遇到的一些问题在 FP 领域中会有所不同。
http://blog.ribomation.com /2009/06/28/the-ups-and-downs-of-erlang/
在函数式编程中，一旦设置了一个变量，它通常是不可变的，因此您不会创建大量新对象。通过递归，您会发现变量更少，因此垃圾收集变得更加重要，这可能有助于解决您遇到的内存问题。
但是，您需要看看您的问题在 FP 中是否能正常工作，因为它并不是适合所有情况的最佳语言。
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.
在 Cesarini / Thompson 的书的最后第一章中，这本书非常好，它讨论了代码 SLOC 与 C++ 电信应用程序的差异：85% 的 C++ 代码是防御性编码、内存管理、高级通信，这些几乎是不必要的在功能上相当的 erlang 代码中。
看看你是否在书店或可以向某人借书。
另请阅读有关硬实时应用程序的研究
http://lambda-the-ultimate.org/node/ 2954章
第 一个>
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
我实在不同意这个问题。要求太多了。
“...这需要动态内存分配。Erlang 如何帮助我确保此分配不会延迟我的音频计算？”。
不太可能存在工具（Erlang 或任何其他语言）可以提前为您提供这种保证。
一直使用的一种方法是计时测试或基准测试。
如果您想证明您的代码不会延迟音频计算，您可能需要自己构建此证明。但证明中的步骤可能依赖于之前的时序测试。
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.