From: Ritesh Kumar <ritesh@cs.unc.edu>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Native executable symtable
Date: Sun, 21 Nov 2004 13:31:34 -0500 [thread overview]
Message-ID: <929F9986-3BEB-11D9-A20F-000A95CDFBE4@cs.unc.edu> (raw)
In-Reply-To: <200411212142.29950.jmg@gaillourdet.net>
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.
next prev parent reply other threads:[~2004-11-21 18:31 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-11 10:18 Alex Baretta
2004-11-11 10:39 ` [Caml-list] " Nicolas Cannasse
2004-11-11 11:09 ` Luca Pascali
2004-11-11 11:55 ` Keith Wansbrough
2004-11-11 12:09 ` Luca Pascali
2004-11-11 12:28 ` Keith Wansbrough
2004-11-11 12:42 ` Luca Pascali
2004-11-11 16:09 ` Richard Jones
2004-11-20 15:44 ` Luca Pascali
2004-11-20 16:03 ` malc
2004-11-20 18:01 ` Alex Baretta
2004-11-20 18:06 ` malc
2004-11-20 18:53 ` Alex Baretta
2004-11-20 19:17 ` malc
2004-11-20 20:07 ` Ritesh Kumar
2004-11-20 22:43 ` The madness of ignoring people Vincenzo Ciancia
2004-11-20 23:10 ` [Caml-list] " malc
2004-11-20 23:25 ` Vincenzo Ciancia
2004-11-21 12:51 ` skaller
2004-11-21 14:14 ` Vincenzo Ciancia
2004-11-21 14:30 ` malc
2004-11-21 3:37 ` [Caml-list] Native executable symtable skaller
2004-11-21 15:59 ` Richard Jones
2004-11-21 20:29 ` skaller
2004-11-21 20:39 ` malc
2004-11-21 23:30 ` Richard W.M. Jones
2004-11-22 3:25 ` skaller
2004-11-21 20:42 ` Jean-Marie Gaillourdet
2004-11-21 18:31 ` Ritesh Kumar [this message]
2004-11-21 23:33 ` Richard Jones
2004-11-21 21:15 ` skaller
2004-11-11 16:23 ` David Brown
2004-11-11 17:27 ` Xavier Leroy
2004-11-11 18:48 ` Alex Baretta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=929F9986-3BEB-11D9-A20F-000A95CDFBE4@cs.unc.edu \
--to=ritesh@cs.unc.edu \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox