[Caml-list] Executable size?

[Caml-list] Executable size?

[John J Lee]

How does O'Caml compare with languages like Haskell (ghc), C and C++ for
executable size?  Does compiled code depend on a runtime library (and how
big is that, if so)?

Are there any easily-identifiable, non-obvious, factors that affect
executable size (I'm talking about end-use factors, rather those resulting
from the design decisions taken by the language designers and
implementors)?

I currently use Python by preference, but I'm interested in a language
(other than C/C++!) that doesn't depend on a big runtime library and
generates "reasonably" small executables -- modems are here to stay for a
while yet.

Thanks for any help


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

Re: [Caml-list] Executable size?

[Richard Jones]

On Wed, Nov 12, 2003 at 04:14:54PM +0000, John J Lee wrote:
> How does O'Caml compare with languages like Haskell (ghc), C and C++ for
> executable size?  Does compiled code depend on a runtime library (and how
> big is that, if so)?

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
list about the merits and problems with linking the runtime
dynamically.

Of course you can always use OCaml as a scripting language (ie.  tiny
"executables" preceeded by #!/usr/bin/ocaml), or distribute the
bytecode, which tends to be small, so you have more choices than the
languages you've listed above.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
"My karma ran over your dogma"

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

Re: [Caml-list] Executable size?

[Dustin Sallings]

On Nov 12, 2003, at 8:14, John J Lee wrote:

> How does O'Caml compare with languages like Haskell (ghc), C and C++ 
> for
> executable size?  Does compiled code depend on a runtime library (and 
> how
> big is that, if so)?

	Well, the bin is bigger than a minimal C app with the same 
functionality.  There is no runtime library required (I build and 
distribute apps).  I somehow don't have ghc on my machines here to do a 
comparison.

> Are there any easily-identifiable, non-obvious, factors that affect
> executable size (I'm talking about end-use factors, rather those 
> resulting
> from the design decisions taken by the language designers and
> implementors)?

	(don't know)

> I currently use Python by preference, but I'm interested in a language
> (other than C/C++!) that doesn't depend on a big runtime library and
> generates "reasonably" small executables -- modems are here to stay 
> for a
> while yet.

	The stuff I build on my Mac ends up being about 300k so far.  That 
seems reasonably small to me.

	I'm not sure what a modem has to do with your distribution, but there 
are options.  You could distribute the source to your app (which will 
be way smaller than the equivalent C or C++ application) and compile 
elsewhere, or you can use the transfer time to bask in your 
productivity and performance gains.  :)

	Python is a bad reference for two reasons:

	1) You don't typically distribute compiled python apps (and when you 
do, it's always bytecode).
	2) Ocaml's runtime is *amazingly* fast.

	I've prototyped a few apps in python before rewriting in ocaml for 
performance.  The speed gains alone are beginning to push python away 
from being my primary utility app language.  I like a lot about the 
language as well.

-- 
Dustin Sallings

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

Re: [Caml-list] Executable size?

[Dustin Sallings]

On Nov 12, 2003, at 9:33, Richard Jones wrote:

> Of course you can always use OCaml as a scripting language (ie.  tiny
> "executables" preceeded by #!/usr/bin/ocaml), or distribute the
> bytecode, which tends to be small, so you have more choices than the
> languages you've listed above.

	I haven't seen the bytecode be much smaller than native executables:

-rwx--x--x  1 dustin  staff   320900 12 Nov 10:06 parseTimingLog*
-rwx------  1 dustin  staff   306614 12 Nov 09:59 parseTimingLogbc*


-- 
Dustin Sallings

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

Re: [Caml-list] Executable size?

[John J Lee]

On Wed, 12 Nov 2003, Richard Jones wrote:

> On Wed, Nov 12, 2003 at 04:14:54PM +0000, John J Lee wrote:
> > How does O'Caml compare with languages like Haskell (ghc), C and C++ for
> > executable size?  Does compiled code depend on a runtime library (and how
> > big is that, if so)?
>
> 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.
[...]

How big is the runtime?  Does the compiler only link in the parts of the
runtime that you use, or do you just non-negotiably get the whole thing
every time you link?

Probably this is a naive question, but: Is it impractical to have a
functional language that uses the C runtime?

Does anyone have recommendations for languages (not necessarily
functional) with a compiler that generates small executables (including
runtime code) for multiple platforms (at least Unix and Windows), with a
decent FFI (foreign function interface), and preferably MS COM support?

Am I really stuck with C++??


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

Re: [Caml-list] Executable size?

[Sven Luther]

On Wed, Nov 12, 2003 at 10:06:52AM -0800, Dustin Sallings wrote:
> 
> On Nov 12, 2003, at 9:33, Richard Jones wrote:
> 
> >Of course you can always use OCaml as a scripting language (ie.  tiny
> >"executables" preceeded by #!/usr/bin/ocaml), or distribute the
> >bytecode, which tends to be small, so you have more choices than the
> >languages you've listed above.
> 
> 	I haven't seen the bytecode be much smaller than native executables:
> 
> -rwx--x--x  1 dustin  staff   320900 12 Nov 10:06 parseTimingLog*
> -rwx------  1 dustin  staff   306614 12 Nov 09:59 parseTimingLogbc*

But then, you can link it dynamically :

  $ file  /usr/bin/ledit
  /usr/bin/ledit: a /usr/bin/ocamlrun script text executable
  $ ls -l  /usr/bin/ledit
  -rwxr-xr-x    1 root     root        94857 2003-09-30 22:40 /usr/bin/ledit

But then, you would only gain for packages using huge C bindings.

Friendly,

Sven Luther

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

Re: [Caml-list] Executable size?

[John J Lee]

On Wed, 12 Nov 2003, Dustin Sallings wrote:

> On Nov 12, 2003, at 8:14, John J Lee wrote:
[...]
> > I currently use Python by preference, but I'm interested in a language
> > (other than C/C++!) that doesn't depend on a big runtime library and
> > generates "reasonably" small executables -- modems are here to stay
> > for a while yet.
>
> 	The stuff I build on my Mac ends up being about 300k so far.  That
> seems reasonably small to me.

Thanks.  From how many lines of source code?

How big is the "hello world" executable?


> 	I'm not sure what a modem has to do with your distribution, but there

If you're distributing executables over the internet to people who use
modems (ie., most people ;-), download size is important.


> are options.  You could distribute the source to your app (which will
> be way smaller than the equivalent C or C++ application) and compile
> elsewhere, or you can use the transfer time to bask in your
> productivity and performance gains.  :)

Unfortunately, neither is an option.  I want to distribute single
executables (for Windows, anyway).  Actually, another issue: can O'Caml
generate Windows DLLs?  ISTR some issue about that...


> 	Python is a bad reference for two reasons:
>
> 	1) You don't typically distribute compiled python apps (and when you
> do, it's always bytecode).
> 	2) Ocaml's runtime is *amazingly* fast.

Well, bad reference for what purposes?  I don't care whether there's
bytecode, machine code, or lemon jelly in my .exes, as long as they're
small :-)  And I don't need any speed above what Python provides.


> 	I've prototyped a few apps in python before rewriting in ocaml for
> performance.  The speed gains alone are beginning to push python away
> from being my primary utility app language.  I like a lot about the
> language as well.

Great.


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

Re: [Caml-list] Executable size?

[Sven Luther]

On Wed, Nov 12, 2003 at 01:06:08PM -0600, Brian Hurt wrote:
> On Wed, 12 Nov 2003, Richard Jones wrote:
> 
> > On Wed, Nov 12, 2003 at 04:14:54PM +0000, John J Lee wrote:
> > > How does O'Caml compare with languages like Haskell (ghc), C and C++ for
> > > executable size?  Does compiled code depend on a runtime library (and how
> > > big is that, if so)?
> > 
> > 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
> > list about the merits and problems with linking the runtime
> > dynamically.
> 
> 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

Mmm (on i386 and with 3.07+2) :

 $ cat hello.ml
 Printf.printf "Hello World!\n"
 $ ocamlc hello.ml -o hello.byte
 $ ls -l hello.byte
 36025 hello.byte
 $ ocamlc hello.ml -custom -o hello.custom
 $ ls -l hello.custom
 181718 hello.custom
 $ ocamlopt hello.ml -o hello.native
 $ ls -l hello.native
 149877 hello.native

That said :

 $ cat hello
 #!/usr/bin/ocamlrun /usr/bin/ocaml
 Printf.printf "Hello World!\n";;
 $ ls -l hello
 68 hello

Friendly,

Sven Luther

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

Re: [Caml-list] Executable size?

[John J Lee]

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?


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


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


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

Re: [Caml-list] Executable size?

[John J Lee]

On Wed, 12 Nov 2003, Sven Luther wrote:

> On Wed, Nov 12, 2003 at 10:06:52AM -0800, Dustin Sallings wrote:
[...]
> But then, you can link it dynamically :
>
>   $ file  /usr/bin/ledit
>   /usr/bin/ledit: a /usr/bin/ocamlrun script text executable
>   $ ls -l  /usr/bin/ledit
>   -rwxr-xr-x    1 root     root        94857 2003-09-30 22:40 /usr/bin/ledit
>
> But then, you would only gain for packages using huge C bindings.
[...]

This may be of interest to others, but personally, it doesn't matter much
to me how it's linked.  The problem is minimising the total data to be
transferred over the wire, including any shared libraries.


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

Re: [Caml-list] Executable size?

[Karl Zilles]

Sven Luther wrote:

 >  $ cat hello.ml
 >  Printf.printf "Hello World!\n"
 >  $ ocamlc hello.ml -o hello.byte
 >  $ ls -l hello.byte
 >  36025 hello.byte
 >  $ ocamlc hello.ml -custom -o hello.custom
 >  $ ls -l hello.custom
 >  181718 hello.custom
 >  $ ocamlopt hello.ml -o hello.native
 >  $ ls -l hello.native
 >  149877 hello.native


Don't forget to strip out debugging info.  When I did that on cygwin I 
dropped from 165K to 100K.


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

Re: [Caml-list] Executable size?

[Dustin Sallings]

On Nov 12, 2003, at 10:36, John J Lee wrote:

>> 	The stuff I build on my Mac ends up being about 300k so far.  That
>> seems reasonably small to me.
>
> Thanks.  From how many lines of source code?

	Probably around 800 of my own and whatever the unix library brings.

> How big is the "hello world" executable?

-rwx--x--x  1 dustin  staff   138452 12 Nov 10:55 a.out*
(or stripped)
-rwx------  1 dustin  staff  111532 12 Nov 10:55 a.out*

>> 	I'm not sure what a modem has to do with your distribution, but there
>
> If you're distributing executables over the internet to people who use
> modems (ie., most people ;-), download size is important.

-rwx------  1 dustin  staff  42425 12 Nov 10:55 a.out.gz*

>> are options.  You could distribute the source to your app (which will
>> be way smaller than the equivalent C or C++ application) and compile
>> elsewhere, or you can use the transfer time to bask in your
>> productivity and performance gains.  :)
>
> Unfortunately, neither is an option.  I want to distribute single
> executables (for Windows, anyway).  Actually, another issue: can O'Caml
> generate Windows DLLs?  ISTR some issue about that...

	I'm happy to say I've never written any code that was intended to run 
under Windows, so I can't answer that question.

>> 	Python is a bad reference for two reasons:
>>
>> 	1) You don't typically distribute compiled python apps (and when you
>> do, it's always bytecode).
>> 	2) Ocaml's runtime is *amazingly* fast.
>
> Well, bad reference for what purposes?  I don't care whether there's
> bytecode, machine code, or lemon jelly in my .exes, as long as they're
> small :-)  And I don't need any speed above what Python provides.

	I wasn't aware you could distribute python exes.  That was my point.  
You can for OS X because of the way applications work in OS X, but 
that's quite different from anything I've seen in Windows (which, 
AFAIK, doesn't even ship with python).

	I have to say I'm really surprised by such a strong emphasis on 
executable size.  I've been learning various programming languages 
specifically because I want to create more reliable applications with 
reasonable performance with less effort (both initially and throughout 
the lifetime of the application).

-- 
Dustin Sallings

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

Re: [Caml-list] Executable size?

[Brian Hurt]

On Wed, 12 Nov 2003, Richard Jones wrote:

> On Wed, Nov 12, 2003 at 04:14:54PM +0000, John J Lee wrote:
> > How does O'Caml compare with languages like Haskell (ghc), C and C++ for
> > executable size?  Does compiled code depend on a runtime library (and how
> > big is that, if so)?
> 
> 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
> list about the merits and problems with linking the runtime
> dynamically.

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.

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.  But in my experience 
(depending upon the program), Ocaml gets a lot more code reuse, and thus 
can actually lead to smaller executables.

Unless you have special constraints, the difference between C program 
sizes and Ocaml program sizes are not enough to be worth worrying about.

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

Re: [Caml-list] Executable size?

[Vitaly Lugovsky]

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

> Unfortunately, neither is an option.  I want to distribute
> single executables (for Windows, anyway).  Actually, another
> issue: can O'Caml generate Windows DLLs?  ISTR some issue about
> that...

 Yes, it can. There exists a patch.


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

Re: [Caml-list] Executable size?

[Brian Hurt]

On Wed, 12 Nov 2003, Sven Luther wrote:

> > 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
> 
> Mmm (on i386 and with 3.07+2) :
> 
>  $ cat hello.ml
>  Printf.printf "Hello World!\n"
>  $ ocamlc hello.ml -o hello.byte
>  $ ls -l hello.byte
>  36025 hello.byte
>  $ ocamlc hello.ml -custom -o hello.custom
>  $ ls -l hello.custom
>  181718 hello.custom
>  $ ocamlopt hello.ml -o hello.native
>  $ ls -l hello.native
>  149877 hello.native
> 
> That said :
> 
>  $ cat hello
>  #!/usr/bin/ocamlrun /usr/bin/ocaml
>  Printf.printf "Hello World!\n";;
>  $ ls -l hello
>  68 hello
>

i386 (Athlon 2200+, actually), Redhat 9.0 and Ocaml 3.07 unpatched:

$ cat temp2.ml
let _ = print_string "Hello, world!";;
 
$ ocamlopt -o temp2 temp2.ml
$ ls -l temp2
-rwxrwxr-x    1 bhurt    bhurt      112213 Nov 12 13:48 temp2
$ cat temp3.c
#include <stdio.h>
 
int main (void) {
    puts("Hello, world!");
    return 0;
}
 
$ gcc -Os -o temp3 temp3.c
$ ls -l temp3
-rwxrwxr-x    1 bhurt    bhurt       11228 Nov 12 13:49 temp3
$


Using printf brings in most of the printf library, and adds about 40K to
the size of the executable.  But you only ever need to include it once.
Doing an ls -l `ocamlc -where`/*.cma shows at most about a meg of total
libraries to include everything in the standard library (I'm assuming that
the 988K toplevellib.cma is only needed by the top level).

If I was willing to let my code out, and download size was important, and
I didn't mind requiring my users to have a compiler/interpreter for the
language installed, then I'd be inclined to just ship bzipped source code
tarballs around.  Maybe with a little compile/install script bundled.  
That way you don't have to ship around the libraries at all, and source
code tends to be smaller than binary executables, and compresses a lot
better than equivelent executables (source code should get at least 10:1 
compression- playing with compressing Ocaml executables I'm only getting 
about 5:2 compression).

That being said, binary executables- especially binary executables with 
any special libraries they need statically linked- have the advantage of 
the making the client need to preinstall as little as possible.
 
> Friendly,
> 
> Sven Luther
> 
> -------------------
> 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
> 

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

Re: [Caml-list] Executable size?

[Basile Starynkevitch]

On Wed, Nov 12, 2003 at 02:40:56PM -0600, Brian Hurt wrote: [....]

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

Sorry to be picky, but this particular claim is wrong:

Ocaml printf routine is implemented in ocaml/stdlib/printf.ml

and does not call C printf related stuff (except perhaps for
float_to_string conversions).

The format4 type is wired inside the compiler, notably inside
ocaml/typing/typecore.ml function type_format.

Actually, I tend to believe that on the contrary

1. Ocaml runtime (mostly the GC) uses the C library

2. Ocaml standard library (and others, notably the Unix module) don't
use that much the C library except thru trivial wrappers (which
essentially deals with Ocaml data representation and its conversion to
native C data types). Most of the standard library is coded in Ocaml,
not in C.

Regards.

-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
Project cristal.inria.fr - 
http://cristal.inria.fr/~starynke --- all opinions are only mine 

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

Re: [Caml-list] Executable size?

[John J Lee]

On Wed, 12 Nov 2003, Dustin Sallings wrote:
[...]
> > If you're distributing executables over the internet to people who use
> > modems (ie., most people ;-), download size is important.
>
> -rwx------  1 dustin  staff  42425 12 Nov 10:55 a.out.gz*

That's interesting, and I admit I'd forgotten about compression, but if
you add standard code to make it a self-extracting archive, you might lose
all of the benefit of compression for really small programs (libz.so is
around 60k on my machine, dunno about standard Windows self-extracting
stuff).  But 100k isn't too bad, so it looks like this isn't a significant
problem for O'Caml, for most cases.

[...]
> 	I wasn't aware you could distribute python exes.  That was my point.

py2exe and McMillan Installer.  I think py2exe actually requires a few
DLLs with the .exe, but Installer can generate single .exes (and supports
platforms other than Windows).  The smallest "hello world" I've seen is
459k, though (that was with some unpublished .exe-creation software).


> 	I have to say I'm really surprised by such a strong emphasis on
> executable size.  I've been learning various programming languages
> specifically because I want to create more reliable applications with
> reasonable performance with less effort (both initially and throughout
> the lifetime of the application).

Most of the time, I don't care about it at all -- would I be using Python
if it were otherwise??  But executable size is the only strong push on me
to use anything other than Python (there's the pull of functional
languages, yes, but that's definitely a pull, not a push :-).


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

Re: [Caml-list] Executable size?

[John J Lee]

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

Re: [Caml-list] Executable size?

[Brian Hurt]

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

Re: [Caml-list] Executable size?

[Brian Hurt]

On Wed, 12 Nov 2003, Karl Zilles wrote:

> Don't forget to strip out debugging info.  When I did that on cygwin I 
> dropped from 165K to 100K.
> 
> 

Good point.  Continuing on my pedantic rant:
$ cat temp2.ml
let _ = Printf.printf "Hello, world!\n";;
                                                                                
$ ocamlopt -o temp2 temp2.ml
$ ls -l temp2
-rwxrwxr-x    1 bhurt    bhurt      150448 Nov 12 15:19 temp2
$ strip temp2
$ ls -l temp2
-rwxrwxr-x    1 bhurt    bhurt      101500 Nov 12 15:24 temp2
$ bzip2 -9v temp2
  temp2:    2.287:1,  3.498 bits/byte, 56.27% saved, 101500 in, 44387 out.
$ ls -l temp2.bz2
-rwxrwxr-x    1 bhurt    bhurt       44387 Nov 12 15:24 temp2.bz2
$ cat temp3.c
#include <stdio.h>
 
int main (void) {
    puts("Hello, world!");
    return 0;
}
 
$ gcc -Os -o temp3 temp3.c
$ ls -l temp3
-rwxrwxr-x    1 bhurt    bhurt       11228 Nov 12 15:27 temp3
$ strip temp3
$ ls -l temp3
-rwxrwxr-x    1 bhurt    bhurt        2768 Nov 12 15:27 temp3
$ bzip2 -9v temp3
  temp3:    2.009:1,  3.983 bits/byte, 50.22% saved, 2768 in, 1378 out.
$ ls -l temp3.bz2
-rwxrwxr-x    1 bhurt    bhurt        1378 Nov 12 15:27 temp3.bz2
$



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

Re: [Caml-list] Executable size?

[David Brown]

On Wed, Nov 12, 2003 at 03:51:54PM -0600, Brian Hurt wrote:

> Actually, about a third of it seems to be debugging information, which 
> goes away with strip.

Be sure you try the executables when you strip them.  Strip on many
systems will remove the byte code from custom executables.

Dave

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

Re: [Caml-list] Executable size?

[Brian Hurt]

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

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

Actually, about a third of it seems to be debugging information, which 
goes away with strip.
 
> > 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.
>

I've been trying hard not to badmouth C++ here :-).  
 
> 
> > 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.
>

It would be an exceeding large program- or a delibertly perverse one- 
which managed to use *all* the libraries Ocaml provides.

And speaking as someone who still gets onto the internet via a 56K baud 
modem, download a megabyte isn't that bad.  I routinely get 5K/second on 
downloads, so a megabyte is ~3.5 minutes.  It's a bathroom break, sure, 
but not unreasonable.
 
-- 
"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

Re: [Caml-list] Executable size?

[Eric Dahlman]

John J Lee wrote:
> On Wed, 12 Nov 2003, Brian Hurt wrote:
>>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++).

C and C++ are not special in this regard, they just happen to be shipped 
with the operating system.  On my box hello world links against  libc.so 
and ld.so which are 1,531,964 and 103,044 bytes respectively.

One way to even things up is require the C version to link to all of its 
libraries statically.  Compiling with 'gcc -static test.c' I get an 
a.out file which is 423,441 bytes long.  So the static linker was able 
to throw better than 2/3 of libc but it still isn't to light.

Really what you need to do is lobby Microsoft and Apple to include ocaml 
as part of the base system install and then things might even out ;-)

-Eric

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

Re: [Caml-list] Executable size?

[Richard Jones]

On Wed, Nov 12, 2003 at 06:21:11PM +0000, John J Lee wrote:
> How big is the runtime?  Does the compiler only link in the parts of the
> runtime that you use, or do you just non-negotiably get the whole thing
> every time you link?

It's really not so huge. You'll have to tell us a bit more about your
situation.

As a general guide, I was recently involved in writing a large
simulation program. We distributed two natively compiled OCaml
programs in a Windows installer, plus many auxiliary files, and the
size of the installer came to between 6 and 8 MB. This was not such an
issue for our users. [The installer was written using NSIS and used
bzip2 compression].

> Probably this is a naive question, but: Is it impractical to have a
> functional language that uses the C runtime?

OCaml links (dynamically) with the C runtime as well. ie. libc on Unix.

> Does anyone have recommendations for languages (not necessarily
> functional) with a compiler that generates small executables (including
> runtime code) for multiple platforms (at least Unix and Windows), with a
> decent FFI (foreign function interface), and preferably MS COM support?

Yes, OCaml! If you want COM support, look at OCam'OLE.

> Am I really stuck with C++??

Well, one would hope not. Supply us with more details about exactly
what the limitations are that you're facing, and we'll be able to
provide some more meaningful information.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
"I wish more software used text based configuration files!"
 -- A Windows NT user, quoted on Slashdot.

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

Re: [Caml-list] Executable size?

[Eric Dahlman]

Brian Hurt wrote:

> Ocaml uses at least some of these libraries itself (although not via
> printf- I was wrong about that).  So, to be fair, you need to statically
> link them into Ocaml binary as well- increasing it's size by half a
> megabyte or so as well.

Who said anything about being fair ;-)  I just was trying to point out 
the problems with the statement that C/C++ didn't need a library.

> As a side note, I just finished downloading a ~10M compressed program 
> (Adobe Acrobat reader) over a 56K baud modem.  Took about 45 minutes or 
> so.  Modems teach you to be patient.  If not, I'll trot out long winded, 
> boring stores about how as a kid I was forced to use a 300 baud modem to 
> connect to the internet, through fourteen feet of snow, up hill, both 
> ways!  :-)
> 
> (eagerly awaiting the IP Transmission over string and 2 tin cans stories 
> from the good old days)

Well you have me beat I started out with 1200 baud of blazing speed.

-Eric


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

Re: [Caml-list] Executable size?

[Brian Hurt]

On Wed, 12 Nov 2003, Eric Dahlman wrote:

> John J Lee wrote:
> > On Wed, 12 Nov 2003, Brian Hurt wrote:
> >>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++).
> 
> C and C++ are not special in this regard, they just happen to be shipped 
> with the operating system.  On my box hello world links against  libc.so 
> and ld.so which are 1,531,964 and 103,044 bytes respectively.

Ocaml uses at least some of these libraries itself (although not via
printf- I was wrong about that).  So, to be fair, you need to statically
link them into Ocaml binary as well- increasing it's size by half a
megabyte or so as well.

As a side note, I just finished downloading a ~10M compressed program 
(Adobe Acrobat reader) over a 56K baud modem.  Took about 45 minutes or 
so.  Modems teach you to be patient.  If not, I'll trot out long winded, 
boring stores about how as a kid I was forced to use a 300 baud modem to 
connect to the internet, through fourteen feet of snow, up hill, both 
ways!  :-)

(eagerly awaiting the IP Transmission over string and 2 tin cans stories 
from the good old days)

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

Re: [Caml-list] Executable size?

[John J Lee]

On Wed, 12 Nov 2003, Brian Hurt wrote:

> On Wed, 12 Nov 2003, Eric Dahlman wrote:
[...]
> As a side note, I just finished downloading a ~10M compressed program
> (Adobe Acrobat reader) over a 56K baud modem.  Took about 45 minutes or
> so.  Modems teach you to be patient.  If not, I'll trot out long winded,
[...]

Modems teach *geeks* to be patient, they teach some other people to go out
into the sunlight occasionally <0.9 wink>.


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

Re: [Caml-list] Executable size?

[John J Lee]

On Wed, 12 Nov 2003, Eric Dahlman wrote:

> John J Lee wrote:
> > On Wed, 12 Nov 2003, Brian Hurt wrote:
> >>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++).
>
> C and C++ are not special in this regard, they just happen to be shipped
> with the operating system.  On my box hello world links against  libc.so
> and ld.so which are 1,531,964 and 103,044 bytes respectively.
[...]

I don't understand what this has to do with what I said in the quote.
Yes, C runtime is present on essentially all systems, but the point is
that C and O'Caml are fundamentally different: with C, you can *ignore*
that runtime, and write a program that simply doesn't use it at all.  Not
so with O'Caml (for perfectly good and sensible reasons).

> One way to even things up is require the C version to link to all of its
[...]

Also, I'm simply looking for a way to distribute code, not trying to start
a pissing contest between C and O'Caml :-) so I'm not interested in
"evening things up".


> Really what you need to do is lobby Microsoft and Apple to include ocaml
> as part of the base system install and then things might even out ;-)

Well, I guess they already have, in the sense that O'Caml has a .NET
implementation -- right?  Always assuming that implementation is more than
the publicity stunt that the Python one was, of course...


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

Re: [Caml-list] Executable size?

[John J Lee]

On Wed, 12 Nov 2003, Richard Jones wrote:
[...]
> size of the installer came to between 6 and 8 MB. This was not such an
> issue for our users. [The installer was written using NSIS and used

Sometimes that's small enough, sometimes not.  No need for debate there...

[...]
> > Am I really stuck with C++??
>
> Well, one would hope not. Supply us with more details about exactly
> what the limitations are that you're facing, and we'll be able to
> provide some more meaningful information.

You already have: the O'Caml runtime executable size overhead is small
enough for me.


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

Re: [Caml-list] Executable size?

[Karl Zilles]

John J Lee wrote:
> Well, I guess they already have, in the sense that O'Caml has a .NET
> implementation -- right?  Always assuming that implementation is more than
> the publicity stunt that the Python one was, of course...

You're referring to F#.  It appears to be more of a research project 
than a full fledged implementation:

http://groups.google.com/groups?selm=fa.qe3mh18.1p1m8jk%40ifi.uio.no

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

Re: [Caml-list] Executable size?

[Nicolas Cannasse]

> How does O'Caml compare with languages like Haskell (ghc), C and C++ for
> executable size?  Does compiled code depend on a runtime library (and how
> big is that, if so)?
>
> Are there any easily-identifiable, non-obvious, factors that affect
> executable size (I'm talking about end-use factors, rather those resulting
> from the design decisions taken by the language designers and
> implementors)?
>
> I currently use Python by preference, but I'm interested in a language
> (other than C/C++!) that doesn't depend on a big runtime library and
> generates "reasonably" small executables -- modems are here to stay for a
> while yet.

If you need COM support , look at OCaml'OLE :
http://tech.motion-twin.com/ocamole
If you need to make Windows DLL , look at ODLL :
http://tech.motion-twin.com/odll
If you need access to the win32 API, look at the ocaml port here :
http://www.speakeasy.org/~hchomsky/ocaml-win32.html

About the size of the executables (in native mode) :
The main problem for a Window developper is that usually when you link a
library staticly, the inclusion is made on a function basis, and not on a
module basis as ocaml do. Then if you have big Ocaml libraries, you should
split them into several indepent modules if feasible to avoid linking all.

I also found recently (is it a 3.07 "feature" - i didn't compare with 3.06
?) that classes compiled natively are taking an huge amount of space : a
~2000 lines library defining ~25 classes with actually not so much code is
compiling into a 100 Ko library in bytecode and into 440 Ko in native...
Using dynamic linking of C stubs will help here , but there is actually no
way of dynlinking Ocaml librairies ( the Dynlink module is not actually
doing any linking.... only loading ).

>From my own experience, executables size are growing faster in OCaml than in
C/C++, with a big leap every time you're linking with an additional
library.... but their size worth it !

Nicolas Cannasse

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

[Caml-list] F-sharp (was: Executable size?)

[Oleg Trott]

On Wednesday 12 November 2003 07:26 pm, Karl Zilles wrote:
> John J Lee wrote:
> > Well, I guess they already have, in the sense that O'Caml has a .NET
> > implementation -- right?  Always assuming that implementation is more
> > than the publicity stunt that the Python one was, of course...
>
> You're referring to F#.  It appears to be more of a research project
> than a full fledged implementation:
>
> http://groups.google.com/groups?selm=fa.qe3mh18.1p1m8jk%40ifi.uio.no

Cc: Don Syme

I'm curious why F# (as I understood it), implements Caml from scratch instead 
of just changing the bytecode compiler in Caml a bit to suite its needs.

By the way, are there benchmarks comparing code produced by ocamlc, ocamlopt 
and F# (together with SML.NET and SML/NJ for that matter) on a variety of 
algorithm and numerics-intensive tasks?

IIRC, when .NET/C# just came out, there were claims that it was almost as fast 
as C.
-- 
Oleg Trott <oleg_trott@columbia.edu>

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

Re: [Caml-list] Executable size?

[Kamil Shakirov]

Hello,

--------- hello.cc ---------------
#include <iostream>

using namespace std;

int main ()
{
	cout << "Hello, world!" << endl;
	return 0;
}
--------- hello.ml ---------------
let _ = print_endline "Hello, world!";;

kamil$ uname -a
Linux tornado.force 2.4.22 #1 Fri Oct 24 12:29:16 MSD 2003 i586 i586 i386 GNU/Linux

kamil$ gcc --version
gcc (GCC) 3.3.2
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

kamil$ ocamlc -version 
3.07[+Shared]

kamil$ g++ -Os -o hello_cpp hello.cc && strip hello_cpp && ldd hello_cpp
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4001d000)
        libm.so.6 => /lib/libm.so.6 (0x400d1000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x400f2000)
        libc.so.6 => /lib/libc.so.6 (0x400fa000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

kamil$ ocamlopt -compact -o hello_mln hello.ml && strip hello_mln && ldd ./hello_mln
        libm.so.6 => /lib/libm.so.6 (0x4001c000)
        libdl.so.2 => /lib/libdl.so.2 (0x4003e000)
        libc.so.6 => /lib/libc.so.6 (0x40041000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

kamil$ g++ -Os -static -o hello_cpp_stat hello.cc && strip hello_cpp_stat

kamil$ ocamlopt -compact -ccopt -static -o hello_mln_stat hello.ml \
       && strip hello_mln_stat

kamil$ ls -l hello_*
-rwxr-xr-x    1 kamil    homeusers     3988 Nov 13 07:00 hello_cpp
-rwxr-xr-x    1 kamil    homeusers   787660 Nov 13 07:00 hello_cpp_stat
-rwxr-xr-x    1 kamil    homeusers    72044 Nov 13 07:00 hello_mln
-rwxr-xr-x    1 kamil    homeusers   458236 Nov 13 07:02 hello_mln_stat

It is more fair in relation to the OCaml. ;)

-- 
 Kamil.

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

Re: [Caml-list] Executable size?

[Richard Jones]

On Thu, Nov 13, 2003 at 07:14:15AM +0300, Kamil Shakirov wrote:
[bogus hello world example]

There are two factors which are actually important when comparing
executable size:

(1) How space efficient are the two compilers when compiling similar code. You
    would have to compare things like two functions which performed the same
    operation, or two equivalent for loops, etc. It's likely that OCaml must
    generate a bit more machine code, because (a) it has to add various
    run-time bounds checks, and (b) it has to do more bit shifts and boxing
    because of the representation of OCaml values.

(2) How much less code do you have to write in OCaml because it has efficiency
    features like polymorphism, garbage collection, data structure matching and
    so on. These features means you have to write, & hence compile, less code
    overall.

I would suggest that (2) outweighs (1), but I've not measured it.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
PTHRLIB is a library for writing small, efficient and fast servers in C.
HTTP, CGI, DBI, lightweight threads: http://www.annexia.org/freeware/pthrlib/

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

Re: [Caml-list] Executable size?

[Sven Luther]

On Wed, Nov 12, 2003 at 06:50:52PM +0000, John J Lee wrote:
> On Wed, 12 Nov 2003, Sven Luther wrote:
> 
> > On Wed, Nov 12, 2003 at 10:06:52AM -0800, Dustin Sallings wrote:
> [...]
> > But then, you can link it dynamically :
> >
> >   $ file  /usr/bin/ledit
> >   /usr/bin/ledit: a /usr/bin/ocamlrun script text executable
> >   $ ls -l  /usr/bin/ledit
> >   -rwxr-xr-x    1 root     root        94857 2003-09-30 22:40 /usr/bin/ledit
> >
> > But then, you would only gain for packages using huge C bindings.
> [...]
> 
> This may be of interest to others, but personally, it doesn't matter much
> to me how it's linked.  The problem is minimising the total data to be
> transferred over the wire, including any shared libraries.

Well, this is because you ship only one ocaml program. But the user
wanting to run many of those will hugely benefit from dynamic linking.
And the distribution integrators (or whatever those are called) will
benefit from it.

Friendly,

Sven Luther

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

Re: [Caml-list] Executable size?

[Sven Luther]

On Wed, Nov 12, 2003 at 02:03:35PM -0600, Brian Hurt wrote:
> Using printf brings in most of the printf library, and adds about 40K to
> the size of the executable.  But you only ever need to include it once.
> Doing an ls -l `ocamlc -where`/*.cma shows at most about a meg of total
> libraries to include everything in the standard library (I'm assuming that
> the 988K toplevellib.cma is only needed by the top level).
> 
> If I was willing to let my code out, and download size was important, and
> I didn't mind requiring my users to have a compiler/interpreter for the
> language installed, then I'd be inclined to just ship bzipped source code
> tarballs around.  Maybe with a little compile/install script bundled.  

Notice that the debian package, which is currently split in ocaml-base
and ocaml, where ocaml-base contains only the ocamlrun executable and
the needed dll.so, and is 400Ko of installed size, will soon be changed
to include a ocaml-interpreter or ocaml-toplevel package, of around 3Mo
installed size, containing the ocaml toplevel and all the .cma/.cmi
needed to run ocaml scripts interactively, without needing to install
the full ocaml package, and all its dependencies.

In this case, you just need to add ocaml-interpreter to the dependency
of the package containing your scripts, and everything will load from
itself when you apt-get it :)))

Naturally this will only work if you run debian, or macos X. Maybe
Cygnus also, but i am not sure.

Friendly,

Sven Luther

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

Re: [Caml-list] Executable size?

[Florian Hars]

Brian Hurt wrote:
> I don't know how many times I've read or written C code like:
[...]
>     outf = fopen(dst, "wb");
>     if (outf == NULL) {
>         fclose(inf);
>         return errno;
>     }

> 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

[...]

This isn't the same code: The C version gets the ressource management right,
while the ocaml version leaks open files like hell.

See http://caml.inria.fr/archives/200307/msg00324.html and followups.

Yours, Florian.

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

Re: [Caml-list] Executable size?

[John J Lee]

On Thu, 13 Nov 2003, Sven Luther wrote:
[...John wrote:]
> > to me how it's linked.  The problem is minimising the total data to be
> > transferred over the wire, including any shared libraries.
>
> Well, this is because you ship only one ocaml program. But the user
> wanting to run many of those will hugely benefit from dynamic linking.
[...]

Sure, but in the Windows world, it's often the case that the user is
running only one executable from one software developer.


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

Re: [Caml-list] Executable size?

[Sven Luther]

On Thu, Nov 13, 2003 at 01:46:57PM +0000, John J Lee wrote:
> On Thu, 13 Nov 2003, Sven Luther wrote:
> [...John wrote:]
> > > to me how it's linked.  The problem is minimising the total data to be
> > > transferred over the wire, including any shared libraries.
> >
> > Well, this is because you ship only one ocaml program. But the user
> > wanting to run many of those will hugely benefit from dynamic linking.
> [...]
> 
> Sure, but in the Windows world, it's often the case that the user is
> running only one executable from one software developer.

Which is why windows has DLLs, no ?

Friendly,

Sven Luther

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

Re: [Caml-list] Executable size?

[Eric Dahlman]

John J Lee wrote:

[snip...]
> I don't understand what this has to do with what I said in the quote.
> Yes, C runtime is present on essentially all systems, but the point is
> that C and O'Caml are fundamentally different: with C, you can *ignore*
> that runtime, and write a program that simply doesn't use it at all.  Not
> so with O'Caml (for perfectly good and sensible reasons).

My point was that if you are making these sorts of comparisons you 
cannot just *ignore* the runtime in the C/C++ case and more importantly 
that C and O'Caml are not fundamentally different in this regard.  By 
definition it is impossible to write a program in C or C++ which does 
not use the respective runtime, it cannot be ignored.

The runtime for any language implements the irreducible primitives of 
that language implementation and is usually quite small.  In the case of 
  C this includes implementations of primitive data types and operators 
not natively supported on a given architecture as well as support for 
the setting up the initial environment.  In the case of gcc this is 
captured in three files which a linked with each C program.  They are

crtbegin.o 1.6k
crtend.o   1.2k
libgcc.a  46.3k

So it would be reasonable to say that the C runtime is 49k.

Now in the case of O'Caml I don't know what the exact numbers are but 
the ZINC interpreter is on the order of 75k and that includes the ocaml 
runtime. So they are really similar, really the only big difference in 
runtime requirements for OCaml is the garbage collector.

Now we have been talking much larger numbers in this thread and that is 
because people have been using some imprecise definitions for runtime. 
These bigger numbers have been including the notion of a standard 
library into the runtime.  In that case C looks smaller because its 
"standard runtime library" is already present on the system awhile 
OCaml's is not.

>>One way to even things up is require the C version to link to all of its
> 
> [...]
> 
> Also, I'm simply looking for a way to distribute code, not trying to start
> a pissing contest between C and O'Caml :-) so I'm not interested in
> "evening things up".

Nor am I (but I bet my language can hit that fly up on the wall...)  The 
   problem is that the measures being discussed were incorrect and 
misleading, I was trying to point out that fact.  When honestly looking 
at things from the standpoint of the runtime C is the smallest OCaml a 
close second and C++ is huge (libsupc++.a is 162k, which I think is the 
one we want).

This is an exact parallel to the old argument that Common Lisp runtime 
is HUGE while Scheme is small.  When you separate out the runtime from 
the library they are really about the same but that does not make for 
good flame wars.

Language implementation and runtime size is really an interesting topic 
but it is not a practical metric for measuring a language.  Furthermore, 
going back to the beginning of this thread it actually doesn't relate to 
your original problems with download size - those are really problems of 
politics, economics and a little engineering.

-Eric

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

Re: [Caml-list] Executable size?

[John J Lee]

On Thu, 13 Nov 2003, Eric Dahlman wrote:
[...]
> My point was that if you are making these sorts of comparisons you
> cannot just *ignore* the runtime in the C/C++ case and more importantly
> that C and O'Caml are not fundamentally different in this regard.  By
> definition it is impossible to write a program in C or C++ which does
> not use the respective runtime, it cannot be ignored.

Hmm, you're right.

I had confused myself, I guess, by absorbing the widespread use of "C
runtime" to mean MSVCRT.DLL (or libc.so, or whatever).

[...]
> the setting up the initial environment.  In the case of gcc this is
> captured in three files which a linked with each C program.  They are
>
> crtbegin.o 1.6k
> crtend.o   1.2k
> libgcc.a  46.3k
>
> So it would be reasonable to say that the C runtime is 49k.
>
> Now in the case of O'Caml I don't know what the exact numbers are but
> the ZINC interpreter is on the order of 75k and that includes the ocaml
> runtime. So they are really similar, really the only big difference in
> runtime requirements for OCaml is the garbage collector.
[...]

OK.  Getting back to the original question again (how to reduce data to be
transferred over the network), both O'Caml and C statically link this
runtime stuff, right?  So, why is O'Caml's "hello world" (compressed) 45k,
to C's 1 or 2k?  Is that 43k the garbage collector?  Or is it mostly that
O'Caml, in contrast to C, is linking in a bunch of stuff from its standard
library that isn't strictly required for "hello world"?  Or something else
again??

Hope I'm not going round in circles here...


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

Re: [Caml-list] Executable size?

[Eric Dahlman]

John J Lee wrote:

>>the setting up the initial environment.  In the case of gcc this is
>>captured in three files which a linked with each C program.  They are
>>
>>crtbegin.o 1.6k
>>crtend.o   1.2k
>>libgcc.a  46.3k
>>
>>So it would be reasonable to say that the C runtime is 49k.
>>
>>Now in the case of O'Caml I don't know what the exact numbers are but
>>the ZINC interpreter is on the order of 75k and that includes the ocaml
>>runtime. So they are really similar, really the only big difference in
>>runtime requirements for OCaml is the garbage collector.
> 
> [...]
> 
> OK.  Getting back to the original question again (how to reduce data to be
> transferred over the network), both O'Caml and C statically link this
> runtime stuff, right?  So, why is O'Caml's "hello world" (compressed) 45k,
> to C's 1 or 2k?  Is that 43k the garbage collector?  Or is it mostly that
> O'Caml, in contrast to C, is linking in a bunch of stuff from its standard
> library that isn't strictly required for "hello world"?  Or something else
> again??

I can't say off hand and I don't have the time to research it.  My back 
of the envelope guess is that it is just not worth the effort to throw 
more stuff away in ocaml.  On a high level you can think of the 
language's runtime as providing the features of the hardware that it 
needs but are not present.  So if you were to port ocaml to run on an 
old Symbolics Lisp machine you could rely on the hardware GC and leave 
that out of your runtime.  This is where C has its first "advantage" in 
that it generally is a close match to the hardware model it is running 
on so there is less for the runtime to implement.  If you want to get an 
idea of what is in such a runtime the documentation for the one GCC uses 
is here:

http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc

Now the second advantage that C has is that it is easier for the linker 
to identify which functions could never be called and strip them out of 
the resulting binary.  That is why in the case of a simple hello world 
program you can get down to basically having none of the runtime code left.

In the old days this was very important and I have used old Unix 
machines that only had static linking.  Those machines also had tiny 
disk drives so there was significant pressure when C was developing to 
make sure you could strip everything down as much as possible.

The basic problem with getting a language like ocaml down that small is 
that there is really no need or desire to do so and even then payoff is 
really small.  You can only leave out the parts you don't use but then 
again if you want to do something cool you will be using those parts. 
You will only win if you are writing primitive C style programs in ocaml 
(not that C programs are primitive but a fancy C program would also pull 
in library dependencies).

So I would say that it is totally possible to "enhance" a language like 
ocaml to generate tiny hello world executables, but I would much rather 
have the bright people working on O'Caml write something of more value. 
  I know that my definition of value is probably at odds with yours in 
this case. ;-)

-Eric



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

Re: [Caml-list] Executable size?

[John J Lee]

On Thu, 13 Nov 2003, Eric Dahlman wrote:
[...]
> So I would say that it is totally possible to "enhance" a language like
> ocaml to generate tiny hello world executables, but I would much rather
> have the bright people working on O'Caml write something of more value.

Sure, that makes sense.


>   I know that my definition of value is probably at odds with yours in
> this case. ;-)

Well, maybe not: 45k is very far from huge even for a puny modem, after
all, and a worthwhile factor of ten improvement over the smallest Python
"hello world" I've seen.  (though that 45k doesn't include decompression
for initial unzipping, so the comparison I make there isn't quite correct)

Thanks for everybody's responses.


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

[Caml-list] float_of_num

[Christophe Raffalli]

  What is the property of float_of_num ? How is it computed ?

Given x : num, I need to find two floats a,b such that a <= x <= b.

Changing the rounding mode and calling float_of_num twice doesnot work 
(this was likely, because I do not know the operation done inside 
float_of_num)

If I know that c = float_of_num is the nearest float, then I can go for
a = x-e and b = x+e with e = x*1e-n with n well chosen.

I think there should be three float_of_num in num.mli:

float_of_num (nearest)
float_of_num_above(nearest above)
float_of_num_bellow (nearest bellow)




-- 
Christophe Raffalli
Universite' de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

te'l: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

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

Re: [Caml-list] Executable size?

[skaller]

On Thu, 2003-11-13 at 03:14, John J Lee wrote:
> How does O'Caml compare with languages like Haskell (ghc), C and C++ for
> executable size?  

For x86, native code compiler:

 520 -rwxrwxr-x    1 skaller  skaller    525379 Nov 15 02:18 flxl
 800 -rwxrwxr-x    1 skaller  skaller    812242 Nov 15 02:18 flxp
 872 -rwxrwxr-x    1 skaller  skaller    887235 Nov 15 02:18 flxm
 920 -rwxrwxr-x    1 skaller  skaller    934253 Nov 15 02:18 flxd
1184 -rwxrwxr-x    1 skaller  skaller   1205490 Nov 15 02:18 flxb
1368 -rwxrwxr-x    1 skaller  skaller   1393890 Nov 15 02:18 flxg

Each program listed is the same as the previous one,
but adds a few more modules: flxl is a lexer,
flxp lex and parse, flxm macro processes, flxd also
does some desugaring (term rewriting), flxb binds code
(does lookups) and flxg generates code (C++ text is output).

Although not evident from this data, the sizes are
roughly proportional to the input text.

A count on the source code is:

 31427  116463  835506 total

[which includes regeression tests, documentation etc ..]


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

Re: [Caml-list] Executable size?

[skaller]

On Thu, 2003-11-13 at 05:21, John J Lee wrote:
> On Wed, 12 Nov 2003, Richard Jones wrote:

> Probably this is a naive question, but: Is it impractical to have a
> functional language that uses the C runtime?

Felix does that. Its own runtime is tiny
(it has a naive exact garbage collector .. only a page of
source code or two).

It also generates shared libraries by default, which don't
include any runtime at all (you invoke the library with
a driver like ocamlrun).

Here is the Hello World program in Felix:
-----------------------
include "std";
print "Hello World\n";
-------------------------

and the output for Linux x86 generated by g++ without optimisation:

  20 -rwxrwxr-x    1 skaller  skaller     18847 Nov 15 02:23 tut101.so

It is run by this program:

  72 -rwxrwxr-x    1 skaller  skaller     69083 Nov 15 02:19 flx_run

[Of course the C and C++ libraries are dynamically linked so are
not included]

> Does anyone have recommendations for languages (not necessarily
> functional) with a compiler that generates small executables (including
> runtime code) for multiple platforms (at least Unix and Windows), with a
> decent FFI (foreign function interface), and preferably MS COM support?
> 
> Am I really stuck with C++??

Felix generates simple ISO C++, so the output is portable.

The foreign function interface  .. well .. example:

header "include <cstdio>";
type file = "FILE*";
fun fopen: string -> file = 'std::fopen($1.data(),"rt")';

MS_COM support you'll have to add yourself.
Should be trivial using the above kind of mechanism.

http://felix.sf.net

It works fine on Linux and has been built with
Cygwin on Windows. Ocaml, Python, and a C++ compiler 
are required. And some courage since it is 'pre-alpha'
software :-)

Read the tutorial to discover the functional features
including first class functions, currying, pattern matching,
etc. Note that polymorhism is fully parametric but compile
time only at the moment since boxing is not used.


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

Re: [Caml-list] Executable size?

[skaller]

On Fri, 2003-11-14 at 02:43, Eric Dahlman wrote:
> John J Lee wrote:

> My point was that if you are making these sorts of comparisons you 
> cannot just *ignore* the runtime in the C/C++ case and more importantly 
> that C and O'Caml are not fundamentally different in this regard.  By 
> definition it is impossible to write a program in C or C++ which does 
> not use the respective runtime, it cannot be ignored.

That is not true for C, unless you are pedantic and refer to ISO C,
and even then, ISO C has a concept of 'hosted' and 'non-hosted'
systems, with the requirements for non-hosted systems
being considerably less.

A very large number of people do in fact build C all the
time without any runtime library at all: embedded systems
typically don't use any runtime.

You can also do this for C++, even g++ can do it I think
by turning off support for features that require run
time support such as exception handling.

Ocaml on the other hand cannot function at all without the gc.


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

Re: [Caml-list] Executable size?

[skaller]

On Fri, 2003-11-14 at 06:58, John J Lee wrote:
> On Thu, 13 Nov 2003, Eric Dahlman wrote:

> 
> OK.  Getting back to the original question again (how to reduce data to be
> transferred over the network), both O'Caml and C statically link this
> runtime stuff, right?  So, why is O'Caml's "hello world" (compressed) 45k,
> to C's 1 or 2k?  Is that 43k the garbage collector?  Or is it mostly that
> O'Caml, in contrast to C, is linking in a bunch of stuff from its standard
> library that isn't strictly required for "hello world"?  Or something else
> again??
> 
> Hope I'm not going round in circles here...

The Ocaml equivalent of a C stub program which dynamically
links to the C run time is bytecode.

Ocaml native code compiler, at least on the x86,
does not generate relocatable code, and so Ocaml 
library functions cannot be dynamically linked.
[At present .. :]

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.


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

Re: [Caml-list] Executable size?

[John J Lee]

On Sat, 16 Nov 2003, skaller wrote:
[...]
> A very large number of people do in fact build C all the
> time without any runtime library at all: embedded systems
> typically don't use any runtime.

When you say "runtime", do you mean stuff like libc.so, or libgcc.a, or
both?

When, if ever, can you avoid linking with libgcc.a (or its equivalent)?
What do you lose by not linking with it?

I don't ask for any practical reason, just to try and sort out how O'Caml,
C and C++ differ here.


> You can also do this for C++, even g++ can do it I think
> by turning off support for features that require run
> time support such as exception handling.
>
> Ocaml on the other hand cannot function at all without the gc.


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

Re: [Caml-list] Executable size?

[John J Lee]

On Sat, 16 Nov 2003, skaller wrote:
> On Fri, 2003-11-14 at 06:58, John J Lee wrote:
[...]
> > OK.  Getting back to the original question again (how to reduce data to be
> > transferred over the network), both O'Caml and C statically link this
> > runtime stuff, right?  So, why is O'Caml's "hello world" (compressed) 45k,
> > to C's 1 or 2k?  Is that 43k the garbage collector?  Or is it mostly that
> > O'Caml, in contrast to C, is linking in a bunch of stuff from its standard
> > library that isn't strictly required for "hello world"?  Or something else
> > again??
> >
> > Hope I'm not going round in circles here...
>
> 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.  So part of the O'Caml standard library is statically
linked into hello world, thus explaining part of the 43k difference?  In
that case, I wonder what the C / O'Caml executable size discrepancy for
"hello world" becomes if you use only OS routines directly?


> Ocaml native code compiler, at least on the x86,
> does not generate relocatable code, and so Ocaml
> library functions cannot be dynamically linked.
> [At present .. :]

So, an O'Caml .DLL or .so is implemented using O'Caml bytecode?


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


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

Re: [Caml-list] Executable size?

[John J Lee]

On Sat, 15 Nov 2003, skaller wrote:
> On Thu, 2003-11-13 at 05:21, John J Lee wrote:
[...]
> > Probably this is a naive question, but: Is it impractical to have a
> > functional language that uses the C runtime?
>
> Felix does that. Its own runtime is tiny
> (it has a naive exact garbage collector .. only a page of
> source code or two).

Thanks for the pointer.  I'd looked at it before and thought it looked
interesting (somebody mentioned it in a comp.lang.python post).


[...]
> > Am I really stuck with C++??
>
> Felix generates simple ISO C++, so the output is portable.
>
> The foreign function interface  .. well .. example:
[...]
> MS_COM support you'll have to add yourself.
> Should be trivial using the above kind of mechanism.

For you, I'm sure.  I'm afraid might make heavy weather of it even so :-(

I've only used COM (when using C++, that is) from MSVC++, and ISTR that
people have said that, for example, using COM from mingw is not easy
unless you know a lot about it (I'm not talking about the language
extensions in MSVC++ -- at least, I don't *think* I am -- but I don't know
what the issues are that cause the alleged problems).


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

Re: [Caml-list] Executable size?

[skaller]

On Sun, 2003-11-16 at 02:01, John J Lee wrote:
> On Sat, 16 Nov 2003, skaller wrote:
> [...]
> > A very large number of people do in fact build C all the
> > time without any runtime library at all: embedded systems
> > typically don't use any runtime.
> 
> When you say "runtime", do you mean stuff like libc.so, or libgcc.a, or
> both?

Neither, crt0 is the key. It isn't a library, but initialisation
code.

> When, if ever, can you avoid linking with libgcc.a (or its equivalent)?
> What do you lose by not linking with it?

You cannot make a traditional 'main' program without some
runtime support. This does things like pass command line
arguments to 'main'. It also sets up registers for the
generated code. For example on the x86 it is common
to set all the segment registers equal. The startup
code may also set up the floating point unit, signal
handlers, etc.

However, no 'library' code is ever required by ISO C
programs unless you actually call the functions or
refer to some variable. Still, if you consider
say 'errno', evil as it is, you might refer to it
even if you never do any file IO, so it had better
be correctly initialised.

Finally, even if you don't do IO, something like
an 'assert' macro might, so perhaps *some* initialisation
of some thing might be done in case you use them,
with the compiler not really knowing if it is necessary or not.

In C++, some initialisation for exception handling, RTTI,
and other stuff may be needed .. even if you don't use it,
it may be included *in case* you use it. In particular,
this may be necessary if you dynamically link to a shared
library that does use these features, and they're global
and have to be set up on startup (RTTI and exception handling
spring to mind here ..)

Even on embedded systems, there is usually initialisation
code, though it is often hand written by the client 
(in assembler).

Finally, there is a special case where you must NOT
use a runtime library, even on a hosted machine.

And that is when bootstrapping the compiler and compiling
the run time :-)

> I don't ask for any practical reason, just to try and sort out how O'Caml,
> C and C++ differ here.

Well, for Ocaml the gc must be set up. In addition, signal and
thread handling might have to be initialised. Perhaps some
data such as command line arguments is fetched by startup
code, whether or not you actually try to access it.

The principal difference between Ocaml and C is that
C is designed to be able to generate things like Linux
kernels, and you certainly don't want to use the standard C
library doing that: you're trying instead to build particular
machine code in a 'high level way', and need to actually
write all the functions you need yourself... since it is
this kernel that actually provides some of the resources
accessed by user space C libraries :-)

Ocaml doesn't try to be a systems programming language,
that's the difference.


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

Re: [Caml-list] Executable size?

[skaller]

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