Browse thread
[Caml-list] Executable size?
[
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: | 2003-11-12 (20:35) |
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