Haskell 对游戏等软实时应用程序的 GC 性能如何？答案

【问题标题】：How about Haskell's GC performance for soft realtime application like games?Haskell 对游戏等软实时应用程序的 GC 性能如何？
【发布时间】：2025-12-04 15:00:01
【问题描述】：

因为我意识到游戏规则逻辑应该处理巨大的复杂性，所以我正在考虑使用游戏领域的非典型语言作为游戏逻辑脚本语言。游戏内脚本的原因是用较少的代码表示复杂的逻辑。所以需要非常好的抽象语言。

但大多数抽象的语言都使用 GC。通常，GC 会导致 CPU 突发负载。基本上它会推迟清除内存操作，并立即执行。对包括游戏和 GUI 在内的实时图形非常重要。

AFAIK，Haskell 的 GC 与其他基于 GC 的语言略有不同，因为它具有不可变属性。很难想象。我找不到任何详细的文档。

有什么不同？对于长时间运行的程序，CPU 是否会突然爆发？（随着时间的推移，负载分布良好，可以为每个滴答调用手动完成 GC 命令）

【问题讨论】：

另见*.com/questions/1263711/…

标签： performance haskell garbage-collection real-time soft-real-time

【解决方案1】：

您可能想在这里查看由 Luke Palmer 发起的线程：http://www.haskell.org/pipermail/haskell-cafe/2010-February/thread.html#73881

【讨论】：

链接应该是haskell.org/pipermail/haskell-cafe/2010-February/073881.html — pipemail 在视觉上标记特定线程方面做得很差。
谢谢。谈话有助于获得乐观的意见。但是我觉得缺乏批准数据...可能仍然没有可验证的应用程序。
总而言之，还有一些希望的空间，但目前我们还没有接近拥有支持 RT 的 GC。
但至少它支持并行。 ;-)

【解决方案2】：

您可能对 this blog post by Simon Marlow 感兴趣，关于将 GHC 从 stop-the-world 集合转移到更并发的、更适合游戏等软实时应用程序的暂停时间。

我自己没有对 GHC 延迟配置文件进行基准测试，但据我了解，那些 0.0007 毫秒的暂停时间可能看起来很短，但它们与堆大小成正比，这对于那个玩具井字游戏程序来说很小，所以真正的堆和暂停时间将大几个数量级。

【讨论】：

谢谢。我决定制作一个消耗大量内存的试点程序:)
那次练习的结果是什么？

【解决方案3】：

您可能对发布于 2011 年，Joyride 实验室。

他们似乎在拥有垃圾收集器方面没有任何问题。

【讨论】：