Re: [Caml-list] Real Time Ocaml

[Erol Akarsu <eakarsu_33@yahoo.com>]

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
<basile.starynkevitch@inria.fr> 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