Haskell 软实时的当前状态 [英] Current state of Haskell soft real-time
问题描述
我正在考虑将 Haskell 用于软实时应用程序.我可能会使用演员，因为它的价值.我想知道是否有人对 Haskell 的当前实时状态有所了解.具体来说，GC 暂停应用程序的问题.我在 Google 上进行了广泛的搜索，发现了 2 多年前的大量讨论，但没有最新的.以下是我找到的一些参考资料:
I'm considering Haskell for a soft real-time app. I will likely use actors, for what it's worth. I'm wondering if anyone has insight into the current state of real-time with Haskell. Specifically, issues with the GC pausing the app. I've Googled extensively, and I've found a great deal of discussions from 2+ years ago, but nothing current. Here are a couple of the references I've found:
我读过的许多旧资料表明，情况(当时)被认为正在改善.有吗?
Much of the older stuff I've read suggests that the situation was (at the time) thought to be improving. Has it?
即使在 2 多年前，也有一些评论表明 Haskell 应用程序可以进行调整，以可靠地将 GC 暂停时间控制在一两毫秒.这看起来很现实吗?
Even 2+ years ago, there were a few comments suggesting Haskell apps could be tuned to reliably keep GC pauses down to a millisecond or two. Does this seem realistic?
推荐答案
所以实时"关注的是 GC 集合引入的延迟.
So the concern for "real time" is the latency introduced by GC collections.
GHC 使用多核垃圾收集器(并且有 一个分支 每线程本地堆).最初是为了提高多核性能而开发的(每个核可以独立收集)通过降低频繁的停止世界同步的成本，出于同样的原因，这恰好也有利于软实时.然而，截至 2013 年，per-thread local heap 尚未合并到 main GHC 中，尽管并行 GC 已经合并.
GHC uses a multicore garbage collector (and there is a branch with per-thread local heaps). Originally developed to improve multcore performance (each core can collect independently) by reducing the cost of frequent stop-the-world synchronisation, this happens to also benefit soft-real time for the same reason. However, as of 2013, the per-thread local heap has not yet been merged into main GHC, although the parallel GC has been.
对于游戏，您应该能够通过使用线程来利用这一点，从而减少对 stop-the-world 本地集合的需求.
For a game you should be able to exploit this, by using threads, and thus reducing the need for stop-the-world local collections.
对于长期存在的对象，在全局堆中，您仍然会冒一些 (ms) GC 的风险.但是，仔细分析例如ThreadScope 将消除这里的障碍.我已经看到通过 GHC 管理的网络堆栈流式传输实时 1080p 视频，而没有明显的 GC 暂停.
For long lived objects, in the global heap, you still risk some (ms) GC. However, careful profiling with e.g. ThreadScope will remove obstacles here. I've seen real time 1080p video streamed through a GHC-managed network stack without noticeable GC pauses.
即使没有这些调整，事情也可能会奏效".Frag 几乎不需要优化，并且在将近 10 年前的现在是软实时的.
And even without these tuneups, things "might just work". Frag needed almost no optimization, and was soft realtime nearly 10 years ago now.
最后，还有很多工具和 GHC 标志可以提高性能:
Finally, there are many tools and GHC flags to improve performance:
- ghc-gc-tune - 获得最佳 GC 标志的图形分解
- 关于吞吐量的建议
- 垃圾的选项收集 - (-Iseconds 可能有用)
- ghc-gc-tune - get graphical breakdown of optimal GC flags
- Advice on throughput
- Options for garbage collection - (-Iseconds can be useful)
然后是编码:使用未装箱的类型(无 GC)，最小化惰性结构分配.以打包形式保存长期存在的数据.测试和基准测试.
And then there is coding: use unboxed types (no GC), minimize lazy structure allocation. Keep long lived data around in packed form. Test and benchmark.
我想你会没事的.
这篇关于Haskell 软实时的当前状态的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
