Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Real Time Ocaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-04-20 (00:16)
From: Brian Hurt <bhurt@s...>
Subject: Re: [Caml-list] Real Time Ocaml
On Fri, 16 Apr 2004, Basile Starynkevitch wrote:

> I do not think that re-coding the Ocaml runtime system for hard
> real-time performance is really realistic (it is doable, but it is a
> big task, requiring significant expertise), and I suspect that the
> resulting system would be slower than today's Ocaml, and will perform
> worse. Real-time garbage collection is tricky and costly (perhaps even
> needing some kind of read barrier). If you recode the Ocaml GC, you
> either have to recode the bytecode interpreter or heavily change some
> tricky parts of the ocamlopt native code generator.

First off, having worked in the realtime world, realtime does not mean
fast.  Quite the contrary, often.  What realtime means is that I can set
deadlines, that a certain amount of work needs to be done within a given
time, and can test and prove that the work will, indeed, be done.  Soft
realtime generally means that missing a deadline, while bad, is not
catastrophic.  Examples include music and video recording/playback.  
Missing a deadline means a skip.  Hard realtime means that there are
catastrophic consequences for missing a deadline- generally, lawyers get
involved if you miss the deadline.  An example here is the brake
controller on your car.  Slower isn't the problem, so long as it's a
constant slower.  It's large differences in time between "common case" and
"worst case".

The only thing non-realtime in Ocaml is the garbage collection.  There are
realtime garbage collectors, which do a certain amount of work every
allocation, so that a) the cost of every allocation is constant (or close
enough), and b) that all the work the collector ever needs to do is 
distributed evenly among the allocations.  The current collector, while 
perfect for non-realtime tasks (due to it's small average cost) is 
horrible for realtime because of the huge difference between the common 
case (5 instructions) and the worst case (mass collection)>

"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: