Haskell 软实时的现状 [英] Current state of Haskell soft real-time
问题描述
我正在考虑将 Haskell 用于软实时应用程序.我很可能会使用演员，因为它值得.我想知道是否有人了解 Haskell 的实时状态.具体来说，GC 暂停应用程序的问题.我在谷歌上进行了广泛的搜索，我发现了 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:
Haskell 对 soft 的 GC 性能如何?像游戏这样的实时应用程序?
我读过的许多较旧的东西都表明情况(当时)被认为正在改善.有吗?
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 还没有被合并到主 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.
对于长期存在的对象，在全局堆中，您仍然有一些(毫秒)GC 的风险.但是，仔细分析，例如ThreadScope 将消除这里的障碍.我见过实时 1080p 视频通过 GHC 管理的网络堆栈流式传输，而没有明显的 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屋！
