www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bloat in Executable

reply codephantom <me noyb.com> writes:
// -----------------------------------
module test;

import core.stdc.stdio;

extern (C) int main()
{
     printf("hello world\n");
     return 0;
}
// -----------------------------------


compiled with dmd v2.077.0, using the -betterC option, I get:

.. on windows ..
23k executable if 32bit (i.e. -m32 )
112k executable if 64bit (i.e. -m64 )

.. on freebsd ..
5.6k executable if 32bit (i.e. -m32 )
7.5k executable if 64bit (i.e. -m64 )

This is not meant to be an anti-windows thing...so let me stop 
those responses right here.

I am genuinely interested in understanding why the 'order of 
magnitude' increase for the 64bit executable on Windows?
Nov 15 2017
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 16 November 2017 at 03:32:26 UTC, codephantom wrote:

 23k executable if 32bit (i.e. -m32 )


It is the statically linked C library. Note that if you remove 
the call to printf, the size is slashed in half.

Windows traditionally didn't do a system-wide C lib, but rather 
the various compiler vendors would do their own. To keep this 
from being a big pain for the end user, static linking can be 
employed as it apparently is with Digital Mars.


 112k executable if 64bit (i.e. -m64 )


I'm not 100% sure this is the same, but I suspect it probably is.


 .. on freebsd ..
 5.6k executable if 32bit (i.e. -m32 )


If you ldd that, you'll see it dynamically links the C library. 
The downside of this is there's less binary compatibility across 
major versions; you are liable to need to recompile from source 
to deal with different libc versions on the system, whereas the 
Windows builds are more likely to just work.
Nov 15 2017
next sibling parent codephantom <me noyb.com> writes:
On Thursday, 16 November 2017 at 03:58:38 UTC, Adam D. Ruppe 
wrote:

 It is the statically linked C library. Note that if you remove 
 the call to printf, the size is slashed in half.

 Windows traditionally didn't do a system-wide C lib, but rather 
 the various compiler vendors would do their own. To keep this 
 from being a big pain for the end user, static linking can be 
 employed as it apparently is with Digital Mars.


Thanks Adam. I understand better now.
Nov 15 2017
prev sibling parent reply Temtaime <temtaime gmail.com> writes:
On Thursday, 16 November 2017 at 03:58:38 UTC, Adam D. Ruppe 
wrote:

 On Thursday, 16 November 2017 at 03:32:26 UTC, codephantom 
 wrote:

 23k executable if 32bit (i.e. -m32 )


 It is the statically linked C library. Note that if you remove 
 the call to printf, the size is slashed in half.

 Windows traditionally didn't do a system-wide C lib, but rather 
 the various compiler vendors would do their own. To keep this 
 from being a big pain for the end user, static linking can be 
 employed as it apparently is with Digital Mars.


 112k executable if 64bit (i.e. -m64 )


 I'm not 100% sure this is the same, but I suspect it probably 
 is.


 .. on freebsd ..
 5.6k executable if 32bit (i.e. -m32 )


 If you ldd that, you'll see it dynamically links the C library. 
 The downside of this is there's less binary compatibility 
 across major versions; you are liable to need to recompile from 
 source to deal with different libc versions on the system, 
 whereas the Windows builds are more likely to just work.


There is system-wide C library. It is named msvc.dll.
TCC uses it producing very small executables.
Nov 17 2017
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Friday, 17 November 2017 at 18:53:57 UTC, Temtaime wrote:

 On Thursday, 16 November 2017 at 03:58:38 UTC, Adam D. Ruppe 
 wrote:

 [...]


 There is system-wide C library. It is named msvc.dll.
 TCC uses it producing very small executables.


https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273
Nov 18 2017
prev sibling parent Joakim <dlang joakim.fea.st> writes:
On Thursday, 16 November 2017 at 03:32:26 UTC, codephantom wrote:

 // -----------------------------------
 module test;

 import core.stdc.stdio;

 extern (C) int main()
 {
     printf("hello world\n");
     return 0;
 }
 // -----------------------------------


 compiled with dmd v2.077.0, using the -betterC option, I get:

 .. on windows ..
 23k executable if 32bit (i.e. -m32 )
 112k executable if 64bit (i.e. -m64 )

 .. on freebsd ..
 5.6k executable if 32bit (i.e. -m32 )
 7.5k executable if 64bit (i.e. -m64 )

 This is not meant to be an anti-windows thing...so let me stop 
 those responses right here.

 I am genuinely interested in understanding why the 'order of 
 magnitude' increase for the 64bit executable on Windows?


If you're worried about executable size, you're probably better 
off using ldc on non-Windows platforms, because David made ldc 
work with the linker's --gc-sections.  I don't think that work 
was ever done for dmd, which is why ldc invokes --gc-sections by 
default for non-MSVC targets but dmd doesn't.
Nov 16 2017