Re: [Caml-list] Real Time Ocaml

[Basile Starynkevitch <basile.starynkevitch@inria.fr>]

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