我正在考慮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