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] > find . -iname '*dylib*' # please note the extra '*' at the 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