Browse thread
RE: [Caml-list] Interactive technical computing
- Robert Fischer
[
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: | 2007-03-09 (15:35) |
From: | Robert Fischer <RFischer@R...> |
Subject: | RE: [Caml-list] Interactive technical computing |
Performance of using F# linking into native applications is better than using OCaml bytecode and linking into native applications? Is F# faster than OCaml bytecode these days? Is the OCaml bytecode's link into dynamic libraries somehow slowing things down? I'm still having trouble seeing what you're getting at -- sorry if I'm being dense. ~~ Robert. -----Original Message----- From: caml-list-bounces@yquem.inria.fr [mailto:caml-list-bounces@yquem.inria.fr]On Behalf Of skaller Sent: Friday, March 09, 2007 9:22 AM To: Robert Fischer Cc: caml-list@inria.fr Subject: RE: [Caml-list] Interactive technical computing On Fri, 2007-03-09 at 08:13 -0600, Robert Fischer wrote: > Performance of Ocaml's bytecode is slower than F#? Really? I wrote: > > As long as you play within the bounds of their VM. This is no different than Ocaml. > > Performance is different :) That's why I use Ocaml native code > exclusively, which doesn't support dynamic loading (yet :) I have no idea about performance of F#: I'm talking about using a Debian based Linux operating system which uses dynamic loading of high performance machine binaries. I once implement a Python interpreter in Ocaml, call Vyper. One of the reasons I gave up was that to extend it with the equivalent of Python's C modules, I had to write the equivalent code in Ocaml and *statically* link it into the program. The main reason for doing this wasn't performance, but to provide bindings to C libraries. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net _______________________________________________ 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