digitalmars.D - why does DMD compile "hello world" to about 500 _kilobytes_ on Mac OS
- Abe (26/26) Aug 31 2014 Dear all,
- Abe (2/2) Aug 31 2014 … that is, the problem whereby DMD produces _huge_ executables
- Abe (2/4) Aug 31 2014 2162
- Jacob Carlborg (4/6) Aug 31 2014 Yes, dynamic libraries are currently only properly supported on Linux.
- Adam D. Ruppe (5/6) Aug 31 2014 The std.stdio package imports most the standard library, so using
- Abe (15/15) Aug 31 2014 Thanks, Adam.
- Adam D. Ruppe (26/27) Aug 31 2014 Yeah. If you used printf instead of writeln, the size gets down
- Abe (25/34) Aug 31 2014 Ah, yes. I was wondering why large amount of code originating in
- Abe (15/15) Aug 31 2014 BTW: FYI: at least on recent-enough versions of Mac OS X, from
- Abe (1/16) Aug 31 2014
- Adam D. Ruppe (4/6) Aug 31 2014 You can do it on Linux with dmd right now (use dmd
- Abe (16/19) Aug 31 2014 Well, it doesn`t look feasible with the current DMD for Mac OS X:
- Joakim (7/11) Aug 31 2014 The Windows version of dmd 2.067 seems to do a better job, with
- Joakim (3/7) Sep 01 2014 Sorry, I measured with the official release of dmd 2.066.0 on
- Joakim (11/18) Sep 01 2014 Oh, I also wanted to say that in this day and age of fast
- Jacob Carlborg (5/11) Aug 31 2014 The size is just as bad there.
- Sean Kelly (7/20) Sep 05 2014 It used to be that a "hello world" D app using printf ran about
- Jacob Carlborg (6/13) Aug 31 2014 It's not just a problem with the linker on OS X. The same problem exists...
- Jacob Carlborg (8/9) Aug 31 2014 The runtime and standard library is statically linked, compared to C
- Dan Olson (28/35) Sep 01 2014 Another option you can use today with OS X is pass in -dead_strip linker
- Dicebot (4/22) Sep 01 2014 This was supposed to be enabled by default in 0.14.0 (it is
- Jacob Carlborg (4/7) Sep 01 2014 It only works for Linux.
- Dicebot (5/12) Sep 01 2014 Any reason why it can't work for OSX in a same way? Assuming LDC
- David Nadlinger (7/11) Sep 01 2014 The reason we don't enable the -dead_strip option of ld64 is
- Jacob Carlborg (4/7) Sep 01 2014 It does not emit these sections the same way, at least not on DMD.
- Dicebot (4/12) Sep 02 2014 Well I am speaking about LDC ;) --gc-sections don't work with
- Marco Leise (15/30) Sep 05 2014 Hey, every new release I go and try it, but found that dub
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (3/6) Sep 05 2014 You meant 4KiB…
- deadalnix (4/10) Sep 05 2014 That is beyond sanity...
- Marco Leise (9/23) Sep 05 2014 Me too... This is the Matrix. Mesmerizing.
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (8/12) Sep 05 2014 Quite impressive what they can do with algorithmic generators,
- Israel (5/10) Sep 05 2014 This made my day.
- Jacob Carlborg (5/7) Sep 01 2014 It will probably clean out TLS, module info and similar data which is
- Abe (9/12) Sep 01 2014 I think that`s the most essential part of why "Hello world" came
- David Nadlinger (6/10) Sep 01 2014 GDC does not strip unneeded stuff by default on any OS, and
- Iain Buclaw via Digitalmars-d (7/15) Sep 02 2014 make install-strip !
- Ary Borenszweig (5/7) Sep 05 2014 The real question is: why does size matter for you?
- deadalnix (3/4) Sep 05 2014 I've been told that it does...
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (8/9) Sep 05 2014 1. download size for PNaCL/asm.js
- Paulo Pinto (6/13) Sep 05 2014 Well, the Go guys are now trying to minimize the footprint of static
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
… that is, the problem whereby DMD produces _huge_ executables for tiny programs.
Aug 31 2014
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
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
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
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
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
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
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
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
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
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
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
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
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
On Monday, 1 September 2014 at 07:36:44 UTC, Joakim wrote:On Monday, 1 September 2014 at 06:07:39 UTC, Joakim wrote: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.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
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
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: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.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.
Sep 05 2014
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
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
Jacob Carlborg <doob me.com> writes:On 01/09/14 01:51, Abe wrote: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 :-(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.
Sep 01 2014
On Monday, 1 September 2014 at 17:23:03 UTC, Dan Olson wrote:Jacob Carlborg <doob me.com> writes: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?On 01/09/14 01:51, Abe wrote: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.2The 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.
Sep 01 2014
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
On Monday, 1 September 2014 at 17:46:11 UTC, Jacob Carlborg wrote:On 2014-09-01 19:28, 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".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.
Sep 01 2014
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
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
On Tuesday, 2 September 2014 at 06:18:27 UTC, Jacob Carlborg wrote:On 01/09/14 20:33, Dicebot wrote:Well I am speaking about LDC ;) --gc-sections don't work with Linux DMD either.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.
Sep 02 2014
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: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. -- MarcoOn 01/09/14 20:33, Dicebot wrote:Well I am speaking about LDC ;) --gc-sections don't work with Linux DMD either.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.
Sep 05 2014
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
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:That is beyond sanity... I love it.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
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: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 MarcoOn Friday, 5 September 2014 at 09:27:41 UTC, Marco Leise wrote:=20 That is beyond sanity... =20 I love it.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
Sep 05 2014
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østadQuite 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-HDepqkhttps://www.youtube.com/watch?v=RCh3Q08HMfs&list=PLA5E2FF8E143DA58CThat is beyond sanity... I love it.
Sep 05 2014
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
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
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
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
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: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.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).
Sep 02 2014
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
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
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
Am 06.09.2014 02:03, schrieb Ary Borenszweig:On 8/31/14, 8:51 PM, Abe wrote:Well, the Go guys are now trying to minimize the footprint of static compilation. The many places 2 MB is a lot. -- PauloPlease 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