我正在考虑Haskell软实时应用程序。我可能会使用演员，因为它是值得的。我想知道是否有人可以通过Haskell洞察当前的实时状态。特别是，GC暂停应用的问题。我已经广泛使用谷歌搜索，并且在2年前我发现了很多讨论，但没有任何最新消息。这里有几个引用的我发现：认为是提高Haskell软实时状态
Using Haskell for sizable real-time systems: how (if?)?
How about Haskell's GC performance for soft realtime application like games?
大部分旧的东西我读过表明，情况是（当时）。有吗？
即使在2年前，也有一些评论建议可以调整Haskell应用程序以可靠地将GC暂停减少到一两毫秒。这看起来很现实吗？
因此，对“实时”的关注是GC集合引入的延迟。
GHC使用多核垃圾回收器（并且有a branch和per-thread local heaps）。最初开发的目的是通过降低频繁停止世界同步的成本来提高多核性能（每个核心can collect independently），但出于同样的原因，这也会使软实时性受益。然而，截至2013年，尽管并行GC已经存在，但每线程本地堆还没有合并到主GHC中。
对于一款游戏，您应该能够利用此功能，通过使用线程，从而减少停止世界本地收藏的需求。
对于长寿命的对象，在全局堆中，仍然存在一些（ms）GC风险。然而，仔细地用例如ThreadScope将在这里消除障碍。我已经看到实时1080p视频流通过GHC管理的网络堆栈，没有明显的GC暂停。
即使没有这些调整，事情“可能会正常工作”。 Frag几乎不需要优化，现在已经有近10年的时间了。
最后，有很多工具和GHC的标志，以提高性能：
然后有编码：使用unboxed类型（无GC），最小化懒惰结构分配。以打包的形式保存长时间的数据。测试和基准。
我想你会没事的。
不要在哪个GHC版本中引入那些每个线程堆？ GHC文档中是否有任何细节？ （我尝试了谷歌搜索，但没有发现任何特别的东西） – Qrilka 2013-03-16 12:07:57
感谢提醒我重温这一点。根据GHC状态报告，每线程GC保留在分支中，而不在主线中。我已链接到报告和状态。 – 2013-03-16 13:13:24
你有没有见过这种情况：
此外，我建议您与Multicore Garbage Collection with Local Heaps纸（ISMM 2011）的作者。
我还没有遇到GC暂停的问题，只要你不使用懒惰列表的一切，你不应该产生太多的垃圾。但是，对于多线程应用程序而言，Sky并不是那么明亮。 GHC仍然没有调度程序和线程优先级，如果你使用线程进行繁重的后台处理，你可以很容易地让你的事件循环饿死。
我不熟悉GHC的严格性分析（http://www.haskell.org/haskellwiki/Performance/Strictness）。我的理解是，在很多情况下，它会自动地严格限制事物，包括列表。 （假设优化级别设置得足够高。）那么你是否说我应该确保以这样的方式进行编码，以便GHC可以在适当的地方使事情变得严格？ – rlkw1024 2013-03-14 16:40:46
GHC 8.2.1有一个名为Compact Regions的功能，可能会有所帮助。
从我的理解来看，它似乎是一种半手动内存管理。 您可以将长时间存储的数据存储在紧凑区域中，并且垃圾收集器不会跟踪它。如果在精简区域中有任何引用，则整个精简区域保持活动状态。一旦没有提及该地区的任何内容，它将被解除分配。如果您对某个地区的内容进行功能更新，则可以将其重新分配到新地区，并且旧区域将被释放。
http://ezyang.com/compact.html
https://hackage.haskell.org/package/compact-0.1.0.1/docs/Data-Compact.html
我还没有看到GC暂停效果如xmonad或断枝。分析工具很容易就足以确保您不会产生大量垃圾。 – 2013-03-06 07:00:41
虽然我对Haskell中的演员有点警惕，但GHC线程研究得更好 – 2013-03-06 07:01:29
我认为这个问题很难根据经验来回答，但作为一个数据，我经常看到亚毫秒gc在软实时应用程序中暂停在相当标准的商品硬件上。 – 2013-03-06 14:43:16