Current state of Haskell soft real-time

2019-01-16 07:36发布

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?

4条回答
Summer. ? 凉城
2楼-- · 2019-01-16 08:10

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

查看更多
我想做一个坏孩纸
3楼-- · 2019-01-16 08:11

Have you seen these:

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

查看更多
三岁会撩人
4楼-- · 2019-01-16 08:16

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.

查看更多
ら.Afraid
5楼-- · 2019-01-16 08:18

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:

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.

查看更多
登录 后发表回答