Tweaking the garbage collector for realtime usage
The GHC documentation lists a lot of tweaks that can be done to the garbage collector. However, Haskell spin-offs like Timber http://www.timber-lang.org/ implement their own incremental garbage collector that is better suitable for real-time usage. Did someone already fiddle with GHC's gc flags so it works better for real-time applications, like games and simulations?
bugfact:
The GHC documentation lists a lot of tweaks that can be done to the garbage collector.
However, Haskell spin-offs like Timber implement their own incremental garbage collector that is better suitable for real-time usage.
Did someone already fiddle with GHC's gc flags so it works better for real-time applications, like games and simulations?
Galois uses GHC's rts for things that have to have low latency. Useful tweaks include: * setting the heap size high * using the threaded runtime system * messing with the scheduler tick rate * patching the rts to avoid slow bits (like deadlock detection) I think since games and simulations aren't strictly "real time" you should be ok. -- Don
Peter Verswyvelen
The GHC documentation lists a lot of tweaks that can be done to the garbage collector. However, Haskell spin-offs like Timber http://www.timber-lang.org/ implement their own incremental garbage collector that is better suitable for real-time usage.
Did someone already fiddle with GHC's gc flags so it works better for real-time applications, like games and simulations?
Under j2me, we just ran the gc every bleeding frame, even after paying painstakingly much attention not to allocate anything while simulating (virtually every vm out there seems to accumulate junk transparently), to keep the runs small/short and framerate even. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.
participants (3)
-
Achim Schneider -
Don Stewart -
Peter Verswyvelen