Version française
Home     About     Download     Resources     Contact us    
Browse thread
Native executable symtable
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Ritesh Kumar <ritesh@c...>
Subject: Re: [Caml-list] Native executable symtable


On Nov 21, 2004, at 3:42 PM, Jean-Marie Gaillourdet wrote:

> Hi,
>
> Am Sonntag, 21. November 2004 16:59 schrieb Richard Jones:
>> It'd be very useful for mod_caml - mod_caml uses Dynlink to load the
>> "scripts" and handlers, and hence is limited to bytecode.  Native code
>> dynamic linking would come in useful.  I'd rather it was part of core
>> OCaml, or available as a separate library which didn't require OCaml
>> itself to be recompiled.
>
> Actually, my impression of the ocaml development is, ocaml is going 
> into the
> same direction as e.g. Java. They are developing a jit compiler to 
> improve
> the performance of the interpreted environment. This is the direction 
> of the
> future as it allows to adapt the native code at runtime, based upon 
> live
> profiling results. We aren't there yet, but this is the direction 
> industry
> and academic world are heading for. Just look at Microsoft's .NET and 
> Sun's
> Java environemt and the huge number of academic papers talking about
> interesting issues with those environemnts. Therefore it might be the 
> right
> time to stop about whining and lamenting the missing native ocaml 
> shared
> library support and to start accepting byte code runtimes as 
> appropriate even
> for performace critical applications.
>
> Regards,
>   Jean-Marie Gaillourdet
>


Well, I just know that currently no bytecoded language (Java/.NET/OcaML 
bytecode)  could give me the 7 to 8 times performance boost in run time 
taken by some of the network topology analysis tools I made for my 
research work. Java was especially bad at those algorithms (may be 
because of its huge memory consumption). There has to be a reason why 
C/native OcaML still take all the performance jewels. You are right 
about the fact that dynamic run-time optimizations might be interesting 
from a performance perspective esp. looking at a functional value 
oriented language like ML. However, it is still a "research" problem 
and has research interest. Native shared libraries has importance in 
making OcaML an otherwise important tool for general day to day 
development. Something like C/C++/Java/.NET. This if you see carefully 
is not a "research" problem.


> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs


--
The human being is a bag of chemicals... nothing else.