From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA28963; Wed, 7 Nov 2001 17:11:23 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA29287 for ; Wed, 7 Nov 2001 17:11:22 +0100 (MET) Received: from beaune.inria.fr (beaune.inria.fr [128.93.8.3]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id fA7GBM119045 for ; Wed, 7 Nov 2001 17:11:22 +0100 (MET) Received: by beaune.inria.fr (8.8.8/1.1.22.3/14Sep99-0328PM) id RAA0000012122; Wed, 7 Nov 2001 17:11:22 +0100 (MET) Date: Wed, 7 Nov 2001 17:11:22 +0100 (MET) From: Damien Doligez Message-Id: <200111071611.RAA0000012122@beaune.inria.fr> To: kok@wtal.de, sevillar@team.ph.inter.net Subject: Re: [Caml-list] Playing Soccer with OCaml Cc: caml-list@pauillac.inria.fr Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >From: "Rafael 'Dido' Sevilla" >Which brings me to a somewhat related question: just how real-time is >OCaml's runtime environment? In short: it has pretty good latency characteristics, but no real-time guarantees. > Is the garbage collection algorithm >real-time, i.e. it uses its own thread to perform GC in parallel to >processing or uses some other technique which guarantees that every cons >performed has an upper bound on the amount of time it will take, >regardless of GC? Note that using a separate thread to perform GC in parallel does not by itself guarantee real-time behaviour. > Most garbage collection algorithms I've seen are not >real-time, in that they can potentially take an unbounded amount of time >that depends on the number of allocated cells. In a real-time GC system, the programmer gives a guarantee that the program will never have more than a fixed amount (declared in advance) of live data, and the system gives a bound on the time needed to perform each allocation. Note that this bound has to be quite low in order to make the real-time guarantees meaningful. The memory management of Objective Caml has low latency almost all the time, thanks to the incremental GC, but we do not give a guaranteed bound. Going all the way to real-time behaviour would be doable (with a lot of work), but it would incur a large overhead, which we are not ready to impose on "normal" users (compilers and proof assistants). That said, I have to add that the normal behaviour of Objective Caml on modern machines should be good enough for interactive games. But if you try to run rocket control algorithms with O'Caml, don't blame us if it fails. > For robotics and other >real-time control and processing problems this is an important question. That's right, but Objective Caml is mainly targetted at Unix systems, which generally do not support real-time anyway. -- Damien ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr