On 29/11/06, Ian Lynagh <[EMAIL PROTECTED]> wrote:
On Wed, Nov 22, 2006 at 03:37:05PM +0000, Neil Davies wrote:
> Ian/Simon(s) Thanks - looking forward to the fix.
I've now pushed it to the HEAD.
Thanks - I'll pull it down and give it a try.
> It will help with the real time enviroment that I've got.
Lazy evaluation and GHC's garbage collector will probably cause
headaches if you want true real time stuff.
So the wisdom goes, but I decided to try it and it works really
nicely. Yes, the GC can introduce additional "jitter", but I can
arrange for GC's to be performed at times more convinient and not on
the time critical path. I'm reliably able to get sub-millisecond
jitter in the wakeup times - which is fine for the application.
Laziness is fine - It'll help later when I can arrange evaluation
outside the time critical path.
Yea, I'd love a non-locking, incremental GC that returned within a
fixed (configurable) time - but until that time....
> Follow on query: Is there a way of seeing the value of this interval
> from within the Haskell program? Helps in the calibration loop.
I don't follow - what interval do you want to know? You can't find out
how long threadDelay took, but the lower bound (in a correct
implementation) is what you ask for and the upper bound is what you get
by measuring it, as you did in your original message.
I was trying to find out (in the running haskell) the value supplied
by (for example) -V RTS flag.
In order to get low jitter you have to deliberately wake up early and
spin - hey what are all these extra cores for! - knowing the
quantisation of the RTS is useful in calibration loop for how much to
wake up early.
Thanks
Ian
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
