Browse thread
Native executable symtable
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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.