31

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?

Community
  • 1
  • 1
rlkw1024
  • 6,455
  • 1
  • 36
  • 65
  • I haven't seen GC pauses effect eg xmonad or frag. The profiling tools are easily sufficient to ensure you're not generating lots of garbage. – Don Stewart Mar 06 '13 at 07:00
  • I'd be a bit wary of actors in Haskell though, GHC threads are much better studied – Don Stewart Mar 06 '13 at 07:01
  • I think this question is quite difficult to answer empirically, but as a datum I regularly see sub-millisecond gc pauses in soft real-time applications on fairly standard commodity hardware. – John L Mar 06 '13 at 14:43

4 Answers4

33

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.

Community
  • 1
  • 1
Don Stewart
  • 137,316
  • 36
  • 365
  • 468
  • 1
    Don in which GHC version were those per-thread heaps introduced? Are there any details in GHC docs? (I tried googling but did not find anything particular) – Qrilka Mar 16 '13 at 12:07
  • 2
    Thanks for reminding me to revisit this. According to the GHC status report, the per-thread GC remains in a branch, and is not in the mainline. I've linked to the reports and the status. – Don Stewart Mar 16 '13 at 13:13
7

Have you seen these:

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

Aleš
  • 8,896
  • 8
  • 62
  • 107
2

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.

kudah
  • 21
  • 1
  • 1
    I'm not familiar with GHC's stricness analysis (http://www.haskell.org/haskellwiki/Performance/Strictness). My understanding is that in many cases, it automagically strictifies things, including lists. (Assuming the optimization level is set high enough.) So are you saying that I should just make sure to code in such a way that GHC can make things strict where appropriate? – rlkw1024 Mar 14 '13 at 16:40
1

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

bwroga
  • 5,379
  • 2
  • 23
  • 25