semanticphilosopher: > Count me in too > > I've got a library that endeavours to deliver 'rate-equivalence' - i.e > there may be some jitter in when the events should have occurred but > their long term rate of progress is stable. > > Testing has shown that I can get events to occur at the right time > within 1ms (99%+ of the time, with 50%+ of the events < 0.5ms) - choose > your O/S carefully though. And this is without resorting to marking the > threads as real time with the kernel. If it matters you can tune the > scheduling to further reduce the timer scheduling latency (at the cost of > more CPU) and increase the fidelity of event timing another order of > magnitude or more. > > As for 'garbage collection ruins my real time properties' argument - > I've been pragmatic about this, you can configure the scheduler to go > and perform a GC if it knows that it is going to sleep for a while (yes, > this doesn't resolve the issues of external events arriving in that time > but read on) but not perform that too often. Turning off GHCs timers (to > stop it garbage collecting after it has actually been idle for a while) > and having code that doesn't create vast amounts of garbage means that a > GC takes <0.1ms. > > Now if I could see within Haskell the amount of heap that has been > recently mutated and some other GC statistics when it was running I > could even decide to schedule that more effectively.
You could actually do this by importing symbols from Stats.c in the runtime (the same variables used for +RTS -sstderr output). I'm not sure anyone's ctually tried this yet though, but the effect would be a program that can monitor its own heap health. -- Don _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
