On Wed, 12 Nov 2003, John J Lee wrote:

> On Wed, 12 Nov 2003, Brian Hurt wrote:
> 
> > On Wed, 12 Nov 2003, Richard Jones wrote:
> [...]
> > > This is not a criticism of OCaml, but the executables do tend to be
> > > quite large. This seems mainly down to the fact that OCaml links the
> > > runtime library in statically. There was previous discussion on this
> [...]
> > This isn't as bad as it sounds.  A simplistic "hello world!" application
> > in Ocaml weighs in at 112K, versus 11K for the equivelent (dynamically
> > linked) C program- almost entirely either statically linked standard
> > libraries and infrastructure (garbage collections, etc.)- stuff that
> > doesn't expand with larger programs.
> 
> 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
wrapper which calls C's printf.  Which is why I haven't bothered comparing
Ocaml's size to C programs being statically linked.  Ocaml is at least
nice enough to only link libraries you are actually using (see the
print_string v. printf results).

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.  Currying, exceptions, etc. also have small size 
penalties.

On the other hand, I would argue that these features, 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:

int copy_file(char * src, char * dst) {
    char * buf;
    FILE * inf;
    FILE * outf;

    if ((src == NULL) || (dst == NULL)) {
        return EINVAL;
    }

    inf = fopen(src, "rb");
    if (inf == NULL) {
        return errno;
    }

    outf = fopen(dst, "wb");
    if (outf == NULL) {
        fclose(inf);
        return errno;
    }

    buf = (char *) malloc(4096);
    if (buf == NULL) {
        fclose(outf);
        fclose(inf);
        return errno;
    }

    blah blah blah you get the idea

Vr.s the same code in Ocaml:

let copyfile src dst =
    let inf = open_in_bin src
    and outf = open_out_bin dst
    and buf = String.make 4096 ' '
    in
    let rec loop () =
        let c = input inf buf 0 4096 in
        if (c > 0) then
            begin
                output outf buf 0 c;
                loop ()
            end
        else
            ()
    in
    loop ()

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.  

> 
> 
> > A naive assumption would be that an Ocaml program is about 100K or so
> > larger than the equivelent C program.  Not much, considering how easy it
> > is to get executables multiple megabytes in size.
> 
> [...]
> > 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
> code written by people other than me, but you seem to mean it in a
> different sense.
> 

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 
trick is that generally the two copies are not exactly identical- if 
the functions are, for example, the length of a linked list, one function 
might operate on a linked list of integers, another a linked list of 
floats.  Ocaml encourages you to program in a generic way- you actually 
have to work at it to write a linked list length routine that *isn't* 
generic, the naive implementation is (so is the optimized version).

Again, this generally isn't a problem in small programs, which easily fit 
into you brain as a whole.  Code reuse becomes more of a trick on moderate 
to large programs, especially moderate to large programs with more than 
one programmer.  How many times have we reimplemented linked lists in C?

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

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

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