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 JAA29117; Fri, 16 Apr 2004 09:56:15 +0200 (MET DST) 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 JAA28918 for ; Fri, 16 Apr 2004 09:56:14 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i3G7vHjq001156; Fri, 16 Apr 2004 09:57:17 +0200 Received: from bourg.inria.fr (bourg.inria.fr [128.93.11.100]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA28356; Fri, 16 Apr 2004 09:56:13 +0200 (MET DST) Received: from starynke by bourg.inria.fr with local (Exim 4.31) id 1BEOCN-0000Qw-5W; Fri, 16 Apr 2004 09:55:43 +0200 Date: Fri, 16 Apr 2004 09:55:43 +0200 To: Brian Hurt , caml-list@inria.fr Subject: Re: [Caml-list] Real Time Ocaml Message-ID: <20040416075542.GA1500@bourg.inria.fr> References: <20040415065154.GB24941@tallman.kefka.frap.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i From: Basile Starynkevitch X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 basile:01 basile:01 2004:99 knowles:99 2004:99 threads:01 model:01 makeblock:01 byterun:01 sizeof:01 sizeof:01 accu:01 extern:01 accu:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, Apr 15, 2004 at 01:44:36PM -0500, Brian Hurt wrote: > On Wed, 14 Apr 2004, Kenneth Knowles wrote: > > > On Wed, Apr 14, 2004 at 07:07:39PM +0200, Basile STARYNKEVITCH wrote: > > > I am coding is an experimental, > > > unsopported, JIT version of it - see my home page at INRIA on > > > http://cristal.inria.fr/~bstarynk > > > > The correct URL appears to be http://cristal.inria.fr/~starynke/ Yes, sorry for the typo. > Question: are you guys experiencing any problems with the cost of > allocation? I can't get a straight answer from the Java people- many > experienced Java programmers still claim that allocation is highly > expensive and avoid if it all possible, while others claim allocation is > cheap (like in Ocaml). Allocation in Java is more expensive than in Ocaml, partly because the Java VM should be able to run concurrently several threads which "simultanously" allocate Java objects (and more generally because of all the synchronisation issues, and the rather heavy object model in Java). Allocation in Ocaml (in particular when you do not use Ocaml objects) is very quick because it justs allocate some (usually small) memory chunk; in the common case, it justs increment a pointer. For example the MAKEBLOCK2 bytecode is interpreted as below (this is a CPP expansion of ocaml/byterun/interp.c) { tag_t tag = *pc++; value block; caml_young_ptr -= (((((2) + 1)) * sizeof (value))); /*1*/ if (caml_young_ptr < caml_young_limit) { /* 2 */ caml_young_ptr += (((((2) + 1)) * sizeof (value))); { sp -= 2; sp[0] = accu; sp[1] = env; caml_extern_sp = sp; }; caml_minor_collection (); { accu = sp[0]; env = sp[1]; sp += 2; }; caml_young_ptr -= (((((2) + 1)) * sizeof (value))); } (*((header_t *) (caml_young_ptr))) = /*3*/ (((header_t) (((header_t) ((2)) << 10) + ((3 << 8)) + (tag_t) ((tag))))); (block) = ((value) (((header_t *) (caml_young_ptr)) + 1));; (((value *) (block))[0]) = accu; /* 4 */ (((value *) (block))[1]) = sp[0]; sp += 1; accu = block; goto *(void *) (((char *) 0) + *pc++); } In the usual case, the caml_young_ptr < caml_young_limit test fails, and what is happenning is a decrement of caml_young_ptr (at 1), a failed compare (at 2), and the filling of the header (at 3) and of the two tuple values (at 4) Regarding the original "real-time Ocaml" thread, I still did not understood what are exactly the real-time needs of the original poster (I guess he just wants to code a sophisticated Web server), and I suspect that they are not really hard real-time, and that running the actual Ocaml runtime system, with some good configuration of the Gc (ie using the Gc module, see http://caml.inria.fr/ocaml/htmlman/libref/Gc.html in particular the Gc.set function) is really enough. 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. Regards -- Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr Project cristal.inria.fr - Inria Rocquencourt http://cristal.inria.fr/~starynke --- all opinions are only mine ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners