Dear all,

Me: a very experienced computer programmer, a newbie to D.

The test program:



   import std.stdio;

   void main() {
       writeln("hello world!");
   }



The result:

   > ls -l foo
   -rwxr-xr-x  1 Abe  wheel  502064 Aug 31 18:47 foo

   > file foo
   foo: Mach-O 64-bit executable x86_64

   > ./foo
   hello world!


Please note: 502064 bytes!!!  [for the curious: 490.296875
kilobytes]


The compiler:

   DMD64 D Compiler v2.066.0
   Copyright (c) 1999-2014 by Digital Mars written by Walter Bright
   Documentation: http://dlang.org/


The OS: Mac OS X 10.6.8


The question: why is Hello World so frickin` huge?!?

[FYI: using "dmd -O" instead of plan "dmd" makes no difference in
the size of the executable]


— Abe

… that is, the problem whereby DMD produces _huge_ executables for tiny programs.

On Sunday, 31 August 2014 at 23:51:41 UTC, Abe wrote:
>        writeln("hello world!");

The std.stdio package imports most the standard library, so using it means a lot of library code is linked into your executable too.

About 200kb is the D runtime code and the rest is standard library code.

> nm foo.o | wc -l
     176

> nm foo | wc -l
    2162

Thanks, Adam.

Is this roughly the same on all relevant platforms for DMD?

I was thinking [hoping?] that maybe this was a problem vis-a-vis the Mac OS X linker, i.e. a situation such that the linker isn`t dropping anything from the referenced libraries, even when the majority of the stuff in those library files is not being used in the currently-being-linked object file.

BTW: using "strip" [no special options] on the executable produces a steep drop in the length of the "nm" output, but only a small change in actual size:

  > ls -l foo
  -rwxr-xr-x  1 Abe  wheel  469112 Aug 31 19:08 foo

  > nm foo | wc -l
    1263


— Abe

On Monday, 1 September 2014 at 00:10:25 UTC, Abe wrote:
> Is this roughly the same on all relevant platforms for DMD?

Yeah. If you used printf instead of writeln, the size gets down to about 250K (on my linux anyway), which can then be stripped down to 160K, showing that the rest of the size comes from pulling in a lot of standard library code.

The rest of that 160 K is the druntime library, stuff like thread support, memory management, etc. that is always present.

It is possible to strip that out too and make really tiny executables (I've gone down to under 3KB before playing with this, as have other people working in the embedded space), but then you don't get any of the library and it is easier said than done.


But you should compare this to other common programming language's sizes:

* Java programs need the user to download like 20 MB of the JRE to run

* Ditto for the .net/mono frameworks

* The ruby interpreter on my computer is about 18 MB

* etc etc etc


Compared to them, D programs are small. The big difference is Java, .net, ruby, python, etc. are already popular enough to have their libraries/support code pre-installed on the user's computer. D programs, on the other hand, carry all their support code with them in each executable (they're statically linked) so they have better odds of just working without the user needing to install other stuff that they prolly don't already have.

> Compared to them, D programs are small. The big difference is Java, .net, ruby, python, etc. are already popular enough to have their libraries/support code pre-installed on the user's computer. D programs, on the other hand, carry all their support code with them in each executable (they're statically linked) so they have better odds of just working without the user
> needing to install other stuff that they prolly don't already have.

Ah, yes.  I was wondering why large amount of code originating in something called a "standard library" was apparently being shoved into an executable.  I guess at this point in the life of Dlang, it is not yet realistic to expect users to have e.g. "libdlang.so" in their "/usr/lib".

It would be nice to have an option to use a systemwide library file and dynamically link it; that way, as a silly example, I could have 10 different D-based "hello world"-sized programs` executables and only one copy of the relevant library code [well, at least of _most_ of it].

BTW: I see what you meant about statically linked:

  > ls -lh /opt/Digital_Mars_D/lib
  -r--r--r--  1 Abe  staff    34M Aug 16 09:08 libphobos2.a

… only an "ar" archive, no ".dylib" file [basically the Mac OS X equivalent of an ".so" file].  :-(

Do you think DMD and Phobos2 could be massaged into giving us the dynamically-linked option with a small-enough amount of time & effort, at least for the first platform to get that option?  [I`m guessing that here, "first" effectively implies "easiest to implement".]

Do you know if GDC and/or LDC do this in a way that makes for small Hello Worlds?  I haven`t yet successfully installed either one of those, sorry, so I can`t test it myself yet.

Thanks again.

— Abe

BTW: FYI: at least on recent-enough versions of Mac OS X, from what I have read, Apple has effectively "forbidden" _true_ static linking, i.e. executables with no dynamic-library dependencies whatsoever.

Here`s the relevant result from the D-based "hello world" executable:

  > otool -L foo
  foo:
	/usr/lib/libSystem.B.dylib          (compatibility version 1.0.0, current version 125.2.11)

	/opt/GCC_4.8.1/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)


[obviously, that second line refers to a GCC that I build & installed myself]

— Abe

On Monday, 1 September 2014 at 00:56:35 UTC, Abe wrote:
> It would be nice to have an option to use a systemwide library file and dynamically link it; that way, as a silly example,

You can do it on Linux with dmd right now (use dmd -defaultlib=libphobos2.so when building), but I don't know about the Mac, and not sure about Windows either.

On Monday, 1 September 2014 at 01:02:27 UTC, Abe wrote:
> BTW: FYI: at least on recent-enough versions of Mac OS X, from what I have read, Apple has effectively "forbidden" _true_ static linking, i.e. executables with no dynamic-library dependencies whatsoever.
>
> Here`s the relevant result from the D-based "hello world" executable:
>
>   > otool -L foo
>   foo:
> 	/usr/lib/libSystem.B.dylib          (compatibility version 1.0.0, current version 125.2.11)
>
> 	/opt/GCC_4.8.1/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
>
>
> [obviously, that second line refers to a GCC that I build & installed myself]
>
> — Abe