[Caml-list] Real Time Ocaml

[Caml-list] Real Time Ocaml

[Erol Akarsu]

Hi:

I am evaluating Ocaml for the implementation language
to build Semantic Web-based services.

I would like to run the required Ocaml application on
a Real Time Operating System. I think Ocaml generates
an intermediate C code and compile it into binary code
or maybe directly into binary one.

We have so many real time OSs that support C language.
In this case, I don't know Ocaml can compile on Real
time OS. This issue is very critical for the project.

Have we tried to run Ocaml application on any real
time os?

Best Regards

Erol Akarsu


	
		
__________________________________
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

Re: [Caml-list] Real Time Ocaml

[Basile STARYNKEVITCH]

On Wed, Apr 14, 2004 at 09:12:27AM -0700, Erol Akarsu wrote:

> I am evaluating Ocaml for the implementation language
> to build Semantic Web-based services.
> 
> I would like to run the required Ocaml application on
> a Real Time Operating System. 

You did not define what you call a real-time OS. Given your
objectives, I guess it does not mean hard real time system.

> I think Ocaml generates an intermediate C code and compile it into
> binary code or maybe directly into binary one.

No. Ocaml comes in two flavors:

   a compiler "ocamlc" generating bytecode (not JVM bytecode, but Ocaml
   bytecode) for a specific VM designed for Ocaml. Thr VM is a fast
   bytecode interpreter coded in C (I am coding is an experimental,
   unsopported, JIT version of it - see my home page at INRIA on
   http://cristal.inria.fr/~bstarynk - this JIT translator uses GNU
   lightning and is still a little buggy - beta stage).

   a compiler "ocamlopt" generating machine code (via assembler, like most C or
   C++ compilers do) for several architectures and systems.

> We have so many real time OSs that support C language.
> In this case, I don't know Ocaml can compile on Real
> time OS. This issue is very critical for the project.

> Have we tried to run Ocaml application on any real
> time os?

Several Ocaml applications are very interactive (e.g. advi... and some
servers). But since you did not define what you mean by real time, it
is hard to guess what exactly are your needs.

Some points (but other collegues could give more details)

  1. The OCaml runtime, in particular its garbage collector, is not
  real time (in the sense, for example, of being able to react thru
  Ocaml code to external events in a stricty bounded & controlled
  manner). However, it can be suited to react in small bounded time
  e.g. less that 100 milliseconds [and perhaps even much less, I
  don't know exactly] on today's >1GHz x86 processors in most of the
  cases. However, on some occasion, a full compacting garbage
  collection is triggered, which may need some significant delay
  (depending upon your memory consumption).

  2. The garbage collector can be tuned for good interactive
  performance. See the Gc module for details, and look into the
  mailing list archives for more.


  3. Porting the core of Ocaml runtime to non-Posix realtime systems
  should be doable (I believe some people did it, ...) but requires a
  significant amount of work.

In a few words, you did not define what you mean by real-time system;
Ocaml is not really real-time, but suitable for interactive programs
(with some tuning of its GC). I think that Ocaml could be used for
servers, including Web servers.


Please note that even standard C is not real-time: there is no
real-time guarantee (or even specification) of the behavior of
essential C library functions like malloc or fprintf.


-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net 
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France

-------------------
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

Re: [Caml-list] Real Time Ocaml

[Kenneth Knowles]

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/

Kenn

-------------------
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

Re: [Caml-list] Real Time Ocaml

[Brian Hurt]

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/
> 

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).

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
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

Re: [Caml-list] Real Time Ocaml

[Basile Starynkevitch]

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

Re: [Caml-list] Real Time Ocaml

[Erol Akarsu]

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

Re: [Caml-list] Real Time Ocaml

[skaller]

On Fri, 2004-04-16 at 22:33, Erol Akarsu wrote:
> Hello Basile,

> 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. 

This kind of telecommunications is not true real time.
I actually worked on precisely this kind of code.
Latency making connections is not an RT issue.
In fact it is common, standardised, practice to
simply dump connections under load -- which is 
known as 'call gapping'.

You do need overal performance,
but there is no critical need
to actually process the data, let alone
do so with an upper limit on latency.
[Its not a nuclear reactor or heart pacemaker]

In other words, Ocaml is strongly recommended!
It will deliver better performance than, for
example, a typical C++ solution. IMHO.

Its very unlikely the GC will load the system 
any more intermittently than a C++ memory  management
system, which, in the long run will be driving
the OS virtual memory manager -- and I've seen lots
of C++ processes thrash on disk access (typically
there are other demands on the disk as well, eg,
your data base ..)

I suspect the major issue will be whether  your
long running process fragment memory enough
that you must call the compacter -- THAT is likely
to 'world stop' for a significant amount of time.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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

Re: [Caml-list] Real Time Ocaml

[Brian Hurt]

On Fri, 16 Apr 2004, Basile Starynkevitch wrote:

> 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.
> 

First off, having worked in the realtime world, realtime does not mean
fast.  Quite the contrary, often.  What realtime means is that I can set
deadlines, that a certain amount of work needs to be done within a given
time, and can test and prove that the work will, indeed, be done.  Soft
realtime generally means that missing a deadline, while bad, is not
catastrophic.  Examples include music and video recording/playback.  
Missing a deadline means a skip.  Hard realtime means that there are
catastrophic consequences for missing a deadline- generally, lawyers get
involved if you miss the deadline.  An example here is the brake
controller on your car.  Slower isn't the problem, so long as it's a
constant slower.  It's large differences in time between "common case" and
"worst case".

The only thing non-realtime in Ocaml is the garbage collection.  There are
realtime garbage collectors, which do a certain amount of work every
allocation, so that a) the cost of every allocation is constant (or close
enough), and b) that all the work the collector ever needs to do is 
distributed evenly among the allocations.  The current collector, while 
perfect for non-realtime tasks (due to it's small average cost) is 
horrible for realtime because of the huge difference between the common 
case (5 instructions) and the worst case (mass collection)>

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
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

Re: [Caml-list] Real Time Ocaml

[Karl Zilles]

Brian Hurt wrote:
> The only thing non-realtime in Ocaml is the garbage collection.  There are
> realtime garbage collectors, which do a certain amount of work every
> allocation, so that a) the cost of every allocation is constant (or close
> enough), and b) that all the work the collector ever needs to do is 
> distributed evenly among the allocations.  The current collector, while 
> perfect for non-realtime tasks (due to it's small average cost) is 
> horrible for realtime because of the huge difference between the common 
> case (5 instructions) and the worst case (mass collection)>

In a realtime garbage collector, how can you prove that you are freeing 
unused memory as fast as you allocate it?  In your attempt to put a 
boundry on time, doesn't it open up the possiblility that you might run 
out of space (even if your program has constant memory usage).

-------------------
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

Re: [Caml-list] Real Time Ocaml

[skaller]

On Tue, 2004-04-20 at 10:31, Karl Zilles wrote:

> In a realtime garbage collector, how can you prove that you are freeing 
> unused memory as fast as you allocate it?

by computing bounds on performance.

For example: once per millisecond you allocate at most 1K objects,
and you have at least 0.2 milliseconds left for the
collector, and the collector collects 1K objects in 0.1
milliseconds worst case .. all garbage is collected
at the start of each 1ms cycle. Assume constant
persistent store: result follows.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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

Re: [Caml-list] Real Time Ocaml

[Jon Harrop]

On Wednesday 14 April 2004 5:12 pm, Erol Akarsu wrote:
> I would like to run the required Ocaml application on
> a Real Time Operating System. I think Ocaml generates
> an intermediate C code and compile it into binary code
> or maybe directly into binary one.

Directly into binary (using the "ocamlopt" compiler).

> We have so many real time OSs that support C language.
> In this case, I don't know Ocaml can compile on Real
> time OS. This issue is very critical for the project.
>
> Have we tried to run Ocaml application on any real
> time os?

I have used ocaml for real-time (interactive) applications and it works 
extremely well. Many people have concerns about the garbage collector but I 
haven't even needed to tweak it to get it to work with my code.

However, it is not clear if you mean hard real-time (as in, if some code in 
your application decides to take more time than expected then the laser it is 
controlling might accidentally chop someone in half). If this is the case 
then ocaml is likely to be unsuitable and you'll be wanting to look for 
specialised tools and OSs.

Cheers,
Jon.

-------------------
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

Re: [Caml-list] Real Time Ocaml

[Hendrik Tews]

Erol Akarsu writes:
   
   Have we tried to run Ocaml application on any real
   time os?
   
I believe, in order to use Ocaml for real time applications you
have to go (at least) the way sketched in Section 9.2 of Luca
Cardellis "Typeful Programming" [1]:

- identify the subset of Ocaml that is heap allocation free
- possibly modify the compiler to enlarge the heap allocation
  free subset
- make sure any programm in this subset does not invoke the
  garbage collector

You also have to do something about signal delivery. 
Then you can write your real time application in this heap
allocation free subset. You could even write the ocaml garbage
collector in Ocaml then.


Of course as others pointed out, depending on your real time
needs Ocaml might already be completely satisfactory. Another
example of Ocaml code in a time critical environment is provided
by the Ensemble project [2]. Garbage collection does not pose any
problems there.


Bye,

Hendrik

[1] http://citeseer.ist.psu.edu/cardelli89typeful.html
[2] http://www.cs.cornell.edu/Info/Projects/Ensemble/index.htm

-------------------
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

Re: [Caml-list] Real Time Ocaml

[Erol Akarsu]

Hello Hendrik,

Thanks for your advice,

How long does it take to write a specific garbage
collector for OCAML for real time environment?
This is beyond my knowledge. Do you know anyone who
can guide me on this project?

But your idea of writing GC in Ocaml seems to me a
cool idea. Writing in OCAML should be more quicker
than low level C,

Actually, I may target on hard-real time systems also
in the future, 
If we can get a real-time Ocaml, it can change the
speed and quality of the product easily,

Thanks

Best Regards

Erol Akarsu



--- Hendrik Tews <tews@tcs.inf.tu-dresden.de> wrote:
> Erol Akarsu writes:
>    
>    Have we tried to run Ocaml application on any
> real
>    time os?
>    
> I believe, in order to use Ocaml for real time
> applications you
> have to go (at least) the way sketched in Section
> 9.2 of Luca
> Cardellis "Typeful Programming" [1]:
> 
> - identify the subset of Ocaml that is heap
> allocation free
> - possibly modify the compiler to enlarge the heap
> allocation
>   free subset
> - make sure any programm in this subset does not
> invoke the
>   garbage collector
> 
> You also have to do something about signal delivery.
> 
> Then you can write your real time application in
> this heap
> allocation free subset. You could even write the
> ocaml garbage
> collector in Ocaml then.
> 
> 
> Of course as others pointed out, depending on your
> real time
> needs Ocaml might already be completely
> satisfactory. Another
> example of Ocaml code in a time critical environment
> is provided
> by the Ensemble project [2]. Garbage collection does
> not pose any
> problems there.
> 
> 
> Bye,
> 
> Hendrik
> 
> [1]
> http://citeseer.ist.psu.edu/cardelli89typeful.html
> [2]
>
http://www.cs.cornell.edu/Info/Projects/Ensemble/index.htm
> 
> -------------------
> 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

Re: [Caml-list] Real Time Ocaml

[Hendrik Tews]

Erol Akarsu writes:
   Date: Thu, 15 Apr 2004 15:33:55 -0700 (PDT)
   Subject: Re: [Caml-list] Real Time Ocaml
   
   How long does it take to write a specific garbage
   collector for OCAML for real time environment?

I don't know either. I only have the impression that real time
garbage collection is really hard. Therefore, I propose: Leave
the Ocaml garbage collector as it is and write your real time
code in an allocation free subset of Ocaml. 

Bye,

Hendrik

-------------------
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

Re: [Caml-list] Real Time Ocaml

[Eric Dahlman]

On Apr 20, 2004, at 3:04 AM, Hendrik Tews wrote:

> Erol Akarsu writes:
>    Date: Thu, 15 Apr 2004 15:33:55 -0700 (PDT)
>    Subject: Re: [Caml-list] Real Time Ocaml
>
>    How long does it take to write a specific garbage
>    collector for OCAML for real time environment?
>
> I don't know either. I only have the impression that real time
> garbage collection is really hard. Therefore, I propose: Leave
> the Ocaml garbage collector as it is and write your real time
> code in an allocation free subset of Ocaml.

As a previous message mentioned the reason there is not much interest 
in hard real time garbage collection for Ocaml is that is is slow, 
slow, slow!!! For most people going to the effort of making a real time 
garbage collector which will make your program run 40% slower just is 
not a rational choice. The problem of real time collection is not 
particularly hard in and of itself it is just that it is of very 
limited utility outside of a very tightly defined application domain.

A great book on garbage collection in general that also includes some 
info on real time garbage collection is  _Garbage Collection_ by 
Richard Jones and Rafael Lins.  Armed with that someone could write a 
real time collector for OCaml running on some sort of a real time OS.

Have Fun!
-Eric

-------------------
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