9

一些背景

我正在为数字媒体编程构建一种编程语言，它应该支持使用非共享消息传递和软实时的并发性（即尽最大努力在不丢失样本或帧且吞吐量恒定的情况下计算音频/视频） .

事实证明，这两个特性很难结合起来，主要是因为一个特殊的限制：实时代码不应该动态分配内存。

我的语言应该可以很容易地实现这样的东西：

  • 一个线程根据参数计算音频样本。例如，这些可以是合成器的不同控件的值。该线程“实时”运行。
  • 一个线程从用户或另一台计算机接收输入以更改这些值。这可能是 GUI 线程，例如，对用户用鼠标转动旋钮做出反应。

我希望用户设置的新值通过队列发送到合成器引擎。现在，如果我只想发送浮点数和其他原子值，问题就不会有趣了。实际上，我希望任何类型的数据都能够从一个线程流向另一个线程，甚至是复杂的对象或数据结构，这对于任何线程和优先级的配置都应该是可能的。如果没有实时方面的动态内存分配，如果不对程序员施加看似任意的限制，这将变得非常困难。

Erlang 经常被宣传为非常适合实时系统。然而，我的理解是 Erlang 永远不会禁止内存分配。如果我也这样做，那么很多问题就会消失，但代价是在执行这些分配的代码中引入了不确定的时间。

问题

那么是什么让 Erlang 如此适合呢？它是否实施了特殊技巧来规避内存分配引起的问题，还是完全忽略了这个问题？是否采用另一种实时方法？

一个例子来说明这个问题

假设我们正在用 Erlang 编写一个合成器，它必须每 50 毫秒产生 64 个样本，否则声音中会出现破裂和爆裂声。我们还假设当我在字符串上移动一些滑块时，必须将一个小对象（假设它是一个列表或包含参数名称和新值的元组）从 GUI 进程发送到音频进程，其中一个副本被创建。这将需要动态内存分配。Erlang 如何帮助我确保这种分配不会延迟我的音频计算？

4

4 回答 4

11

实时代码可以动态分配内存，只是需要更加小心。

在真正的硬实时中，动态内存处理将成为在确定系统是否可以在分配的时间内完成它必须做的事情时必须考虑的另一个因素。硬是最坏的情况。

在软实时中，检查动态内存处理不会花费太多时间并导致停顿时间过长通常就足够了。软是一般情况。

erlang 系统非常适合软实时应用程序，动态内存处理相当有效，通常不会导致任何明显的暂停。虽然它可能会引入一些非确定性，但它本身不应该有任何问题。我的意思是，如果时间对您很重要，那么您无论如何都应该为应用程序计时，例如，以便音频样本按时“到达”。

如果 erlang 是您的应用程序的正确语言，这是一个完全不同的问题。尚未真正优化的一件事是数值计算。Erlang 当然可以做到，但它没有低级语言的速度。它们通常对使用 erlang 的应用程序类型并不重要。但是还有 Wings 3D，这是一个开源细分建模器，灵感来自 Izware 的 Nendo 和 Mirai，它是用 erlang 编写的。所以一切都不是没有希望的。:-)

真正找出答案的唯一方法是编写一个小测试并尝试一下。另一个问题是詹姆斯提到的，您更喜欢使用哪种类型的语言？

于 2009-10-15T00:29:21.427 回答
4

由于 Erlang 是由 Ericsson 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 中是否能很好地解决，因为它不是适用于所有情况的最佳语言。

于 2009-10-14T21:25:04.550 回答
1

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.

于 2011-01-06T00:53:05.037 回答
1

在第 1 章结尾，Cesarini / Thompson 的书非常好，它讨论了代码 SLOC 与 C++ 电信应用程序的区别：85% 的 C++ 代码是防御性编码、内存管理、高级通信，这些几乎是不必要的在功能可比的 erlang 代码中。

看看你是在书店里还是可以从别人那里借来的。

还阅读了有关硬实时应用程序的研究

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

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

于 2009-10-15T02:28:34.493 回答