From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA24697; Sat, 15 Nov 2003 20:08:30 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA23425 for ; Sat, 15 Nov 2003 20:08:29 +0100 (MET) Received: from mail2.tpgi.com.au (mail.tpgi.com.au [203.12.160.58]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id hAFJ8Q123251 for ; Sat, 15 Nov 2003 20:08:27 +0100 (MET) Received: from 203-213-83-146-syd-ts15-2600.tpgi.com.au (203-213-83-146-syd-ts15-2600.tpgi.com.au [203.213.83.146]) by mail2.tpgi.com.au (8.12.10/8.12.10) with ESMTP id hAFJ8NrL031187; Sun, 16 Nov 2003 06:08:24 +1100 Subject: Re: [Caml-list] Executable size? From: skaller Reply-To: skaller@ozemail.com.au To: John J Lee Cc: caml-list@inria.fr In-Reply-To: References: <3FB2B050.8050901@atcorp.com> <3FB3A6A6.8010108@atcorp.com> <1068903697.25869.101.camel@pelican> Content-Type: text/plain Message-Id: <1068919657.25869.276.camel@pelican> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 16 Nov 2003 05:07:37 +1100 Content-Transfer-Encoding: 7bit X-Kaspersky-Antivirus: Passed X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 ozemail:01 stub:01 dynamically:01 implying:01 c's:01 printf:01 dynamically:01 statically:01 footprint:01 implemented:01 patched:01 ocamlrun:01 footprint:01 toplevels:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, 2003-11-16 at 02:13, John J Lee wrote: > On Sat, 16 Nov 2003, skaller wrote: > > The Ocaml equivalent of a C stub program which dynamically > > links to the C run time is bytecode. > > And, you're implying, even C's "hello world" *is* using the C standard > library, because of printf -- and O'Caml is using it's standard library > for the same reason. I think I'm saying that a 'fair' comparison would be between C shared library partitioning of code, and Ocaml driver program (top level) which loads bytcode dynamically: when Ocaml is statically linking native code it is going for all out blinding speed and ease of moving the application executable around, instead of a small footprint and portability of the application. > So, an O'Caml .DLL or .so is implemented using O'Caml bytecode? If you want dynamic loading, you have to use either bytecode or a patched native code compiler (at least on the x86/Linux platform). This is a bit of a pain, I'd love to generate shared libraries. [I only use the native code system] > > > In my opinion, you best bet is to generate bytecode > > and distribute that. Your clients WILL have to download > > the bigger ocamlrun driver harness, but hopefully > > only once. > > That's not useful in the case where the user is only downloading one > program, unfortunately. True it will not reduce the footprint. Perhaps it will even be larger. However, it *will* help make the code more portable, since you can separate the one off task of building a custom top level for each platform, and then building platform independent application code. I do this in Felix, and luckily for me the standard toplevel has all the resources I need, so I can just rely on the Ocaml team to build toplevels for each system, and let the client build my product using bytecode if there is no native compiler for their platform. If you do that, the footprint will vary depending on the target platform. (Which it will anyhow I suppose :-) ------------------- 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