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 OAA14772; Fri, 16 Apr 2004 14:33:51 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA14430 for ; Fri, 16 Apr 2004 14:33:50 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from web12405.mail.yahoo.com (web12405.mail.yahoo.com [216.136.173.132]) by concorde.inria.fr (8.12.10/8.12.10) with SMTP id i3GCXmYM026836 for ; Fri, 16 Apr 2004 14:33:49 +0200 Message-ID: <20040416123348.74144.qmail@web12405.mail.yahoo.com> Received: from [208.251.204.71] by web12405.mail.yahoo.com via HTTP; Fri, 16 Apr 2004 05:33:48 PDT Date: Fri, 16 Apr 2004 05:33:48 -0700 (PDT) From: Erol Akarsu Subject: Re: [Caml-list] Real Time Ocaml To: Basile Starynkevitch , Brian Hurt , caml-list@inria.fr In-Reply-To: <20040416075542.GA1500@bourg.inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at concorde 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 re-writing:01 ebusiness:99 run-time:01 speedup:01 basile:01 2004:99 knowles:99 2004:99 threads:01 model:01 makeblock:01 byterun:01 sizeof:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Hello Basile, I appreciate your comments. It is true that current Ocaml implementation is using best optimized libraries. Re-writing Ocaml run time may need a lot of investment. What I was thinking that with real-time ebusiness we should achieve same performance as current softswitches . That means whenever you make phone call, you call should be connected in say 1 seconds, maximum = 2 seconds. In ocaml case, Let's say one time 500 users are making call simultaneously and at some point Ocaml starts GC algorithm. Maybe, next user will have some waiting time because of GC overhead. Could you correct me If I am wrong? When we compile Ocaml to binary code, still GC will be effective during run-time? Or, GC will be active during only interpreted environment? Yesterday, I found TILT http://www-2.cs.cmu.edu/~fox/til.html. They claim that using type information during compile time will end up 3 times speedup and 1/5 binary code size as compared to SML/NJ. Are Ocaml a type-directed compiler like TILT? Thanks Erol Akarsu --- Basile Starynkevitch wrote: > 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 __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html ------------------- 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