garbage collection - Current state of Haskell soft real-time

Question

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:

Using Haskell for sizable real-time systems: how (if?)?

How about Haskell's GC performance for soft realtime application like games?

Much of the older stuff I've read suggests that the situation was (at the time) thought to be improving. Has it?

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?

Answer 1

So the concern for "real time" is the latency introduced by GC collections.

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.

For a game you should be able to exploit this, by using threads, and thus reducing the need for stop-the-world local collections.

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.

And even without these tuneups, things "might just work". Frag needed almost no optimization, and was soft realtime nearly 10 years ago now.

Finally, there are many tools and GHC flags to improve performance:

• ghc-gc-tune - get graphical breakdown of optimal GC flags
• Advice on throughput
• Options for garbage collection - (-Iseconds can be useful)

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.

I think you'll be fine.