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.