Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Executable size?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: John J Lee <jjl@p...>
Subject: Re: [Caml-list] Executable size?
On Wed, 12 Nov 2003, Brian Hurt wrote:

> On Wed, 12 Nov 2003, John J Lee wrote:
[...]
> > OK.  Is that 100K difference for "hello world" (which doesn't necessarily
> > stay the same for larger programs, as you say below) simply a result of
> > the fact that C has the "unfair" advantage of already having its runtime
> > sitting on everyone's hard drive already?
>
> Actually, I think Ocaml uses C's runtime libraries and builds on top of
> them.  For example, if I understand things correctly, Ocaml's printf is a
[...]
> In addition to a more complicated and complete standard library and
> bultins, Ocaml also has garbage collection, which is non-trivial to
> implement.  I wouldn't be surprised if half or more of that 100K of
> overhead is just the GC.

Ah, of course!


> Currying, exceptions, etc. also have small size penalties.

OK.  I'm now enlightened on that point -- clearly, O'Caml's runtime is an
absolute requirement for an O'Caml program (unlike C/C++).



> On the other hand, I would argue that these features [are very
> valuable], while bloating the application.  Which is exactly the sort of
> thing small "benchmark"  programs don't show.  I don't know how many
> times I've read or written C code like:
[...]
> Vr.s the same code in Ocaml:
[...]

Absolutely, I'm quite in agreement there.


> The ocaml executable code for copyfile function will be smaller than the C
> version, simply because the ocaml version takes advantage of various
> features of the larger ocaml library and infrastructure- especially (in
> this case) exceptions and garbage collection.

Right.  Obviously, this kind of thing is highly dependent on exactly what
facilities are provided in your execution environment.  For example,
Windows provides a huge amount of stuff that you can build on if you have
access to Win32 and COM, without needing to statically link anything
(regardless of the language you're using).


> > [...]
> > > Ocaml gets a lot more code reuse, and thus can actually lead to smaller
> > > executables.
> >
> > I don't understand what you mean by that (probably my fault).  What do you
> > mean by "code reuse" here?  I usually understand that phrase to mean using
> [...]
> I was using it in the most literal sense- using code more than once, in
> more than one way.  In general, it's much better to have only one copy of
> a function, used in two places, than two copies of the function.  The
[...]

Got you.  The template explosion problem in C++, eg.


> > > Unless you have special constraints, the difference between C program
> > > sizes and Ocaml program sizes are not enough to be worth worrying about.
> >
> > I don't really agree that the problem of distributing simple (few lines of
> > code) applications in small executables is all that "special".  Certainly
> > there are *many* applications where you don't need that; equally, there
> > are quite a few where you do need/want that.
>
> I was thinking of special cases where the difference of a 100K or 1M or so
> is the difference between working and not working.  If you are, for
> example, trying to fit your program on a 512K ROM, Ocaml's overhead might
> be a problem.

Or if people are willing to download 100k but not 1M.


John

-------------------
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