Current state of Haskell soft real-time

问题:

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?

回答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.

回答2:

Have you seen these:

• Current state of garbage collection in Haskell (July 2012)
• also, check out the following discussion at Lambda the Ultimate

Also, I would recommend contacting the authors of the Multicore Garbage Collection with Local Heaps paper (ISMM 2011).

回答3:

I haven't encountered problems with GC pauses, as long as you don't use lazy lists for everything, you shouldn't generate too much trash.

Sky isn't so bright for multi-threaded applications, however. GHC still doesn't have a scheduler with thread priorities, if you use threads for heavy background processing, you can easily starve your event loop.

回答4:

GHC 8.2.1 has a feature called Compact Regions that could be helpful.

From my understanding, it seems to be a type of semi-manual memory management. You can store long-lived data in a Compact Region and the garbage collector does not trace it. If there are any references to anything in the Compact Region, the entire Compact Region is kept alive. Once there are no references to anything in the region, it will be deallocated. If you make functional updates to the contents of a region you can re-allocate it in a new region and the old region will be freed.

http://ezyang.com/compact.html
https://hackage.haskell.org/package/compact-0.1.0.1/docs/Data-Compact.html