我正致力于为数字媒体编程构建一种编程语言，它应该支持使用无共享消息传递和软实时的并发（即尽可能地计算音频/视频而不会丢失样本或帧，并使用恒定吞吐量）。
事实证明，这两个特性难以组合，主要是因为一个特定的约束：实时代码不应该动态分配内存。
我的语言应该可以很容易地实现这样的事情：
我希望用户设置的新值通过队列发送到合成器引擎。如果我只想发送浮点数和其他原子值，那么问题就不会很有趣了。实际上，我希望任何类型的数据能够从一个线程流到另一个线程，甚至是复杂的对象或数据结构，这对于线程和优先级的任何配置都应该是可能的。如果没有实时动态内存分配，如果不对程序员施加任何似乎任意的限制，这就变得非常困难。
Erlang经常被宣传为适合实时系统。我的理解是，Erlang从不会禁止内存分配。如果我做了同样的事情，那将会导致许多问题消失，代价是在执行这些分配的代码中引入非确定性时序。
那么是什么让Erlang如此合适呢？它是否实现了特殊的技巧来规避内存分配引起的问题，还是完全忽略了这个问题呢？它需要另一种实时方法吗？
让我们假设我们在Erlang中编写一个合成器，它必须每50毫秒产生64个样本，否则声音中会出现裂缝和爆裂声。让我们假设当我在字符串上移动一些滑块时，一个小对象（假设它是一个列表或包含参数名称和新值的元组）必须从GUI进程发送到音频进程，其中a副本已创建。这将需要动态内存分配。 Erlang如何帮助我确保这个分配不会延迟我的音频计算？
答案 0 :(得分：10)
实时代码可以动态分配内存，只需要更加小心。
在真正的硬实时中，动态内存处理将成为另一个在制定系统时是否能够做到的时候必须考虑的因素分配。艰难是最糟糕的情况。
在 soft 实时中，通常可以检查动态内存处理是否会占用太多时间并导致暂停时间过长。软是平均情况。
erlang系统对于软实时应用来说非常好，动态内存处理相当有效，通常不会引起任何明显的暂停。虽然它可能会引入一些非确定性，但这本身不应该是你的任何问题。我的意思是，如果时间对你很重要，那么无论如何你应该为应用程序计时，例如以便音频样本按时“到达”。
如果erlang是您的应用的正确语言，这是一个完全不同的问题。尚未真正优化的一件事是数值计算。 Erlang当然可以做到，但它没有低级语言的速度。对于使用了erlang的应用程序类型，它们通常并不重要。但是又有一个Wings 3D，一个开源的细分模型，灵感来自Izware的Nendo和Mirai，用erlang编写。所以一切都不是没有希望的。 ： - ）
真正找到答案的唯一方法是编写一个小测试并试一试。另一个问题是詹姆斯提到的，你更喜欢使用哪种语言？
答案 1 :(得分：3)
由于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，因为它不适合所有情况。
答案 2 :(得分：1)
最后的第1章，Cesarini / Thompson这本书非常出色，它讨论了代码SLOC差异与C ++电信应用程序：85％的C ++代码是防御性编码，内存管理，高级通信，这些都是在功能相当的erlang代码中几乎没有必要。
看看你是在书店还是可以向某人借钱。
还阅读有关硬实时应用的研究
答案 3 :(得分：1)
我真的不同意这个问题。这要求太多了。
“......这需要动态内存分配.Erlang如何帮助我确保这个分配不会延迟我的音频计算？”。
工具（Erlang或任何其他语言）不太可能提前为您提供此保证。
一直使用的方法是时序测试或基准测试。
如果您想证明您的代码不会延迟您的音频计算，您可能需要自己构建此证明。但证据中的步骤可能依赖于之前的时间测试。