www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - why does DMD compile "hello world" to about 500 _kilobytes_ on Mac OS

reply "Abe" <abe149 remove.this.part.gmail.com> writes:
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
Aug 31 2014
next sibling parent reply "Abe" <abe149 nospam.gmail.com> writes:
… that is, the problem whereby DMD produces _huge_ executables 
for tiny programs.
Aug 31 2014
next sibling parent "Abe" <abe149 nospam.gmail.com> writes:
 nm foo.o | wc -l


      176


 nm foo | wc -l


     2162
Aug 31 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 01/09/14 01:57, Abe wrote:

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


Yes, dynamic libraries are currently only properly supported on Linux.

-- 
/Jacob Carlborg
Aug 31 2014
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Aug 31 2014
parent reply "Abe" <abe149 nospam.gmail.com> writes:
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
Aug 31 2014
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Aug 31 2014
next sibling parent reply "Abe" <abe149 nospam.gmail.com> writes:
 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
Aug 31 2014
next sibling parent reply "Abe" <abe149 nospam.gmail.com> writes:
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
Aug 31 2014
parent reply "Abe" <abe149 nospam.gmail.com> writes:
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
Aug 31 2014
parent reply "Abe" <abe149 nospam.gmail.com> writes:
Sorry: accidentally hit something on the keyboard that the Mac 
and/or Chromium interpreted as "post it right now".  :-(


This msg. is to confirm that "If you used printf instead of 
writeln […]", from an above msg. from Adam, is also correct on 
Mac OS X [64-bit Intel].

Given this source code:

   import core.stdc.stdio;
   void main() {
     printf("hello world!\n");
   }


… the size is now down to 334744 bytes [w/o any stripping], i.e. 
326.8984375 kbytes for those so inclined.  The length of the 
output from "nm" for _this_ executable is 1552 lines [again, w/o 
any stripping].

— Abe
Aug 31 2014
parent "Abe" <abe149 nospam.gmail.com> writes:
Also: the same printf-based D code as I gave in my previous post 
results in the following [still Mac OS X 64-bit Intel].

   > nm bar.o | wc -l
       22

   > strip bar
   > nm bar | wc -l
      915

— Abe
Aug 31 2014
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Aug 31 2014
parent reply "Abe" <abe149 nospam.gmail.com> writes:
 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.


Well, it doesn`t look feasible with the current DMD for Mac OS X:

   > cd /opt/Digital_Mars_D_2.066.0
   > find . -iname '*dylib'
[nothing found]

end
   ./src/druntime/src/rt/dylib_fixes.c


Reading "./src/druntime/src/rt/dylib_fixes.c" seems to indicate 
that DMD has at least _some_ support for Mac OS X dynamic 
libraries, but IDK how much and under which circumstances.


If anybody with a Windows installation of DMD would care to chime 
in, I`d be interested to read what that side of the triangle 
looks like vis-a-vis the linking and size-of-executable 
issue/issues.

My thanks again to Adam.

— Abe
Aug 31 2014
next sibling parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Monday, 1 September 2014 at 01:20:02 UTC, Abe wrote:

 If anybody with a Windows installation of DMD would care to 
 chime in, I`d be interested to read what that side of the 
 triangle looks like vis-a-vis the linking and 
 size-of-executable issue/issues.


The Windows version of dmd 2.067 seems to do a better job, with 
the executable coming in at 144 KB for the 32-bit version linked 
with optlink and 270 KB for the 64-bit version linked with the MS 
linker.

I believe the blocker on shared libraries for OS X is getting TLS 
working across multiple D shared libraries.
Aug 31 2014
parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Monday, 1 September 2014 at 06:07:39 UTC, Joakim wrote:

 The Windows version of dmd 2.067 seems to do a better job, with 
 the executable coming in at 144 KB for the 32-bit version 
 linked with optlink and 270 KB for the 64-bit version linked 
 with the MS linker.


Sorry, I measured with the official release of dmd 2.066.0 on 
Windows 7 x64 and miswrote the version as 2.067.
Sep 01 2014
parent "Joakim" <dlang joakim.airpost.net> writes:
On Monday, 1 September 2014 at 07:36:44 UTC, Joakim wrote:

 On Monday, 1 September 2014 at 06:07:39 UTC, Joakim wrote:

 The Windows version of dmd 2.067 seems to do a better job, 
 with the executable coming in at 144 KB for the 32-bit version 
 linked with optlink and 270 KB for the 64-bit version linked 
 with the MS linker.


 Sorry, I measured with the official release of dmd 2.066.0 on 
 Windows 7 x64 and miswrote the version as 2.067.


Oh, I also wanted to say that in this day and age of fast 
internet connections and large disk drives, a basic runtime size 
cost of less than half a MB is nothing and not worth worrying 
about.  My smartphone model that came out two years ago has 64 GB 
of space, I have trouble finding HD videos to fill it up with. :)

We should try to minimize binary size, simply because all 
optimizations are helpful, but it's not a high priority.  If 
you're trying to use D in the embedded space, as Adam and others 
have, presumably you know what you're doing and can hack it down 
yourself.
Sep 01 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 01/09/14 03:20, Abe wrote:


 Reading "./src/druntime/src/rt/dylib_fixes.c" seems to indicate that DMD
 has at least _some_ support for Mac OS X dynamic libraries, but IDK how
 much and under which circumstances.


Dynamic libraries are not yet properly supported.


 If anybody with a Windows installation of DMD would care to chime in,
 I`d be interested to read what that side of the triangle looks like
 vis-a-vis the linking and size-of-executable issue/issues.


The size is just as bad there.

-- 
/Jacob Carlborg
Aug 31 2014
prev sibling parent "Sean Kelly" <sean invisibleduck.org> writes:
On Monday, 1 September 2014 at 00:19:43 UTC, Adam D. Ruppe wrote:

 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.


It used to be that a "hello world" D app using printf ran about
65K.  At some point, a lot of bloat appeared in the form of a
ModuleInfo object for each imported module, and these objects
themselves grew in size for reasons I can't recall.  That bloat
has since been trimmed down, but I believe there's still work to
be done there.
Sep 05 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 01/09/14 02:10, Abe wrote:

 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.


It's not just a problem with the linker on OS X. The same problem exists 
on Linux and Windows as well. On Linux with LDC the --gc-sections flag 
is used which will reduce the binary size.

-- 
/Jacob Carlborg
Aug 31 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 01/09/14 01:51, Abe wrote:


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


The runtime and standard library is statically linked, compared to C 
where it's dynamically linked. Also unnecessary symbols are not 
stripped. DMD on OS X doesn't currently support dynamic libraries. LDC 
has the --gc-sections flag, enabled by default. This will significantly 
reduce the since of the binary.

-- 
/Jacob Carlborg
Aug 31 2014
next sibling parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
Jacob Carlborg <doob me.com> writes:


 On 01/09/14 01:51, Abe wrote:


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


 The runtime and standard library is statically linked, compared to C
 where it's dynamically linked. Also unnecessary symbols are not
 stripped. DMD on OS X doesn't currently support dynamic libraries. LDC
 has the --gc-sections flag, enabled by default. This will
 significantly reduce the since of the binary.


Another option you can use today with OS X is pass in -dead_strip linker
option to get rid of unreachable symbols. It works good with LDC.

using LDC - the LLVM D compiler (0.14.0):
  based on DMD v2.065 and LLVM 3.4.2

$ ldc2 -L-dead_strip hello.d
$ ls -lh hello
-rwxr-xr-x  1 dan  staff   305K Sep  1 10:01 hello
$ strip hello
$ ls -lh hello
-rwxr-xr-x  1 dan  staff   228K Sep  1 10:01 hello

A version using puts instead of writeln shrinks more.

ldc2 helloputs -L-dead_strip
$ ldc2 -L-dead_strip helloputs.d
$ ls -lh helloputs
-rwxr-xr-x  1 dan  staff   243K Sep  1 10:01 helloputs
$ strip helloputs
$ ls -lh helloputs
-rwxr-xr-x  1 dan  staff   181K Sep  1 10:01 helloputs

Otherwise LDC makes really big binaries:

$ ldc2 hello.d
$ ls -lh hello
-rwxr-xr-x  1 dan  staff   2.2M Sep  1 10:01 hello
$ strip hello
$ ls -lh hello
-rwxr-xr-x  1 dan  staff   1.9M Sep  1 10:01 hello

When I try -dead_strip with DMD, I get runtime SEGV with simple writeln
hello world :-(
Sep 01 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 1 September 2014 at 17:23:03 UTC, Dan Olson wrote:

 Jacob Carlborg <doob me.com> writes:


 On 01/09/14 01:51, Abe wrote:


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


 The runtime and standard library is statically linked, 
 compared to C
 where it's dynamically linked. Also unnecessary symbols are not
 stripped. DMD on OS X doesn't currently support dynamic 
 libraries. LDC
 has the --gc-sections flag, enabled by default. This will
 significantly reduce the since of the binary.


 Another option you can use today with OS X is pass in 
 -dead_strip linker
 option to get rid of unreachable symbols. It works good with 
 LDC.

 using LDC - the LLVM D compiler (0.14.0):
   based on DMD v2.065 and LLVM 3.4.2


This was supposed to be enabled by default in 0.14.0 (it is 
exactly what ld --gc-sections does). Probably some issue with ld 
argument wrapper for whatever lines OSX uses?
Sep 01 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-09-01 19:28, Dicebot wrote:


 This was supposed to be enabled by default in 0.14.0 (it is exactly what
 ld --gc-sections does). Probably some issue with ld argument wrapper for
 whatever lines OSX uses?


It only works for Linux.

-- 
/Jacob Carlborg
Sep 01 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 1 September 2014 at 17:46:11 UTC, Jacob Carlborg wrote:

 On 2014-09-01 19:28, Dicebot wrote:


 This was supposed to be enabled by default in 0.14.0 (it is 
 exactly what
 ld --gc-sections does). Probably some issue with ld argument 
 wrapper for
 whatever lines OSX uses?


 It only works for Linux.


Any reason why it can't work for OSX in a same way? Assuming LDC 
does emit ModuleInfo & Co sections the same way it does on Linux, 
using OSX specific alternative to --gc-sections should "just 
work".
Sep 01 2014
next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Monday, 1 September 2014 at 18:33:44 UTC, Dicebot wrote:

 Any reason why it can't work for OSX in a same way? Assuming 
 LDC does emit ModuleInfo & Co sections the same way it does on 
 Linux, using OSX specific alternative to --gc-sections should 
 "just work".


The reason we don't enable the -dead_strip option of ld64 is 
simply because nobody had time to make sure it works as intended. 
For Linux, I made the necessary adjustments to get --gc-sections 
to function correctly while I was working on the related code for 
runtime loading anyway.

David
Sep 01 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 01/09/14 20:33, Dicebot wrote:


 Any reason why it can't work for OSX in a same way? Assuming LDC does
 emit ModuleInfo & Co sections the same way it does on Linux, using OSX
 specific alternative to --gc-sections should "just work".


It does not emit these sections the same way, at least not on DMD.

-- 
/Jacob Carlborg
Sep 01 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 2 September 2014 at 06:18:27 UTC, Jacob Carlborg
wrote:

 On 01/09/14 20:33, Dicebot wrote:


 Any reason why it can't work for OSX in a same way? Assuming 
 LDC does
 emit ModuleInfo & Co sections the same way it does on Linux, 
 using OSX
 specific alternative to --gc-sections should "just work".


 It does not emit these sections the same way, at least not on 
 DMD.


Well I am speaking about LDC ;) --gc-sections don't work with
Linux DMD either.
Sep 02 2014
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 02 Sep 2014 07:03:52 +0000
schrieb "Dicebot" <public dicebot.lv>:


 On Tuesday, 2 September 2014 at 06:18:27 UTC, Jacob Carlborg
 wrote:

 On 01/09/14 20:33, Dicebot wrote:


 Any reason why it can't work for OSX in a same way? Assuming 
 LDC does
 emit ModuleInfo & Co sections the same way it does on Linux, 
 using OSX
 specific alternative to --gc-sections should "just work".


 It does not emit these sections the same way, at least not on 
 DMD.


 
 Well I am speaking about LDC ;) --gc-sections don't work with
 Linux DMD either.


Hey, every new release I go and try it, but found that dub
will still crash when linked with --gc-sections, so some
symbols need to be "added as GC roots".

That said with -defaultlib=phobos2 (picking up the .so
version) the file size is:

                   48 KiB  !!!

after `strip main` it comes down to:

                   34 KiB  !!!

Only when you think about how people put 5 minutes of a
stunning 3D gfx demo into 64 KiB you start to worry about 34
KiB for "Hello World!" again.

-- 
Marco
Sep 05 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 5 September 2014 at 09:27:41 UTC, Marco Leise wrote:

 Only when you think about how people put 5 minutes of a
 stunning 3D gfx demo into 64 KiB you start to worry about 34
 KiB for "Hello World!" again.


You meant 4KiB…

https://www.youtube.com/watch?v=RCh3Q08HMfs&list=PLA5E2FF8E143DA58C
Sep 05 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 5 September 2014 at 11:50:37 UTC, Ola Fosheim Grøstad
wrote:

 On Friday, 5 September 2014 at 09:27:41 UTC, Marco Leise wrote:

 Only when you think about how people put 5 minutes of a
 stunning 3D gfx demo into 64 KiB you start to worry about 34
 KiB for "Hello World!" again.


 You meant 4KiB…

 https://www.youtube.com/watch?v=RCh3Q08HMfs&list=PLA5E2FF8E143DA58C


That is beyond sanity...

I love it.
Sep 05 2014
next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 05 Sep 2014 19:38:13 +0000
schrieb "deadalnix" <deadalnix gmail.com>:


 On Friday, 5 September 2014 at 11:50:37 UTC, Ola Fosheim Gr=C3=B8stad
 wrote:

 On Friday, 5 September 2014 at 09:27:41 UTC, Marco Leise wrote:

 Only when you think about how people put 5 minutes of a
 stunning 3D gfx demo into 64 KiB you start to worry about 34
 KiB for "Hello World!" again.


 You meant 4KiB=E2=80=A6

 https://www.youtube.com/watch?v=3DRCh3Q08HMfs&list=3DPLA5E2FF8E143DA58C


=20
 That is beyond sanity...
=20
 I love it.


Me too... This is the Matrix. Mesmerizing.
Of course printing 12 characters to stdout is still much more
involved than even 5 of those ... demos ... with their graphics
shaders, metaballs, fish eye effects, camera fly throughs and
polyphonic synthesizer music.

--=20
Marco
Sep 05 2014
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 5 September 2014 at 19:38:14 UTC, deadalnix wrote:

 On Friday, 5 September 2014 at 11:50:37 UTC, Ola Fosheim Grøstad

 https://www.youtube.com/watch?v=RCh3Q08HMfs&list=PLA5E2FF8E143DA58C


 That is beyond sanity...

 I love it.


Quite impressive what they can do with algorithmic generators, 
distance fields, dsp and compression.

Minimalistic insanity:

Music in one line of c-code:
https://www.youtube.com/watch?v=tCRPUv8V22o

9 minutes music video in 23 bytes:
https://www.youtube.com/watch?v=7lcQ-HDepqk
Sep 05 2014
prev sibling parent "Israel" <tl12000 live.com> writes:
On Friday, 5 September 2014 at 09:27:41 UTC, Marco Leise wrote:

 Am Tue, 02 Sep 2014 07:03:52 +0000
 schrieb "Dicebot" <public dicebot.lv>:
 Only when you think about how people put 5 minutes of a
 stunning 3D gfx demo into 64 KiB you start to worry about 34
 KiB for "Hello World!" again.


This made my day.

Anyways yea, i tried using LDC and --gc-sections as lflags in dub
but i cant get dub to play nice with LDC. I think Dub just uses
DMD be default and cannot be changed, im not sure.
Sep 05 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-09-01 19:23, Dan Olson wrote:


 When I try -dead_strip with DMD, I get runtime SEGV with simple writeln
 hello world :-(


It will probably clean out TLS, module info and similar data which is 
not reachable from the main function.

-- 
/Jacob Carlborg
Sep 01 2014
prev sibling parent reply "Abe" <abe149 nospam.gmail.com> writes:
First: thanks to Joakim and yourself for all the recent replies.



 unnecessary symbols are not stripped.


I think that`s the most essential part of why "Hello world" came 
out so big for me.



 LDC has the --gc-sections flag, enabled by default. This will 
 significantly reduce the since of the binary.


Thanks to both you and Joakim for that.

Do you guys — or anybody else — know what the situation is with 
GDC?  Does it strip out unneeded sections/symbols/both, or is it 
just dumping everything into the executable like DMD-on-Mac-OS-X 
seems to do?

— Abe
Sep 01 2014
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Monday, 1 September 2014 at 22:17:13 UTC, Abe wrote:

 Do you guys — or anybody else — know what the situation is with 
 GDC?  Does it strip out unneeded sections/symbols/both, or is 
 it just dumping everything into the executable like 
 DMD-on-Mac-OS-X seems to do?


GDC does not strip unneeded stuff by default on any OS, and 
generates by far the biggest executables in my experience (though 
some of it is due to druntime/Phobos debug info which you can 
manually strip out afterwards).

David
Sep 01 2014
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 2 September 2014 01:03, David Nadlinger via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 1 September 2014 at 22:17:13 UTC, Abe wrote:

 Do you guys — or anybody else — know what the situation is with GDC?  Does
 it strip out unneeded sections/symbols/both, or is it just dumping
 everything into the executable like DMD-on-Mac-OS-X seems to do?



 GDC does not strip unneeded stuff by default on any OS, and generates by far
 the biggest executables in my experience (though some of it is due to
 druntime/Phobos debug info which you can manually strip out afterwards).


make install-strip !

Though I'd imagine that libgcc is likely one of the main contributors
to the notably stouter application size vs dmd/ldc.  Someone should
actually study where the symbols come from.

Iain.
Sep 02 2014
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 8/31/14, 8:51 PM, Abe wrote:

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


The real question is: why does size matter for you?

A simple "hello world" program in Go is 2 megabytes. That's four times 
the size in D. I don't know if people complain about that.

I efficiency matters most.
Sep 05 2014
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 6 September 2014 at 00:03:02 UTC, Ary Borenszweig 
wrote:

 The real question is: why does size matter for you?


I've been told that it does...
Sep 05 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 6 September 2014 at 00:03:02 UTC, Ary Borenszweig 
wrote:

 The real question is: why does size matter for you?


1. download size for PNaCL/asm.js
2. ease of low level debugging/transparency
3. potential cache pollution
4. embedded programming / SoCs
5. bloat signals loss of control over the design
6. programer aesthetics
Sep 05 2014
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 06.09.2014 02:03, schrieb Ary Borenszweig:

 On 8/31/14, 8:51 PM, Abe wrote:

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


 The real question is: why does size matter for you?

 A simple "hello world" program in Go is 2 megabytes. That's four times
 the size in D. I don't know if people complain about that.

 I efficiency matters most.


Well, the Go guys are now trying to minimize the footprint of static 
compilation.

The many places 2 MB is a lot.

--
Paulo
Sep 05 2014