D.gnu - Generated binary size
- Dicebot (21/21) Sep 13 2013 I was experimenting with `--gc-sections` effect on D code (with
- Joseph Rushton Wakeling (3/4) Sep 13 2013 Can you expand on this? Never heard of it before and can't find it in g...
- Dicebot (10/15) Sep 13 2013 `--gc-sections` is ld flag that enabled garbage collection of
- Joseph Rushton Wakeling (13/20) Sep 13 2013 Ahh, OK.
- Dicebot (7/15) Sep 13 2013 It is exactly what `gdc -fdata-sections -Xlinker --gc-sections
- Dicebot (19/24) Sep 13 2013 On my machine:
- Joseph Rushton Wakeling (3/12) Sep 13 2013 Tried it. It reduces 12 MB executables to 11 MB -- but if I manually ex...
- Dicebot (4/7) Sep 13 2013 Then it is likely to be marked as referenced by something :( Can
- Joseph Rushton Wakeling (4/6) Sep 13 2013 Sorry, I'm talking nonsense. I managed to accidentally build using ldmd...
- Iain Buclaw (9/17) Sep 13 2013 I expect this is because the phobos/druntime libraries shipped with
- Iain Buclaw (7/24) Sep 13 2013 In this way, I'd also expect those who build gdc from source would
- Johannes Pfau (10/15) Sep 13 2013 The example from the original post is still valid though. Even with a
- Joseph Rushton Wakeling (3/7) Sep 13 2013 Could be. I do build with the --enable-checking=release option, what el...
- Johannes Pfau (5/15) Sep 13 2013 Use
- Joseph Rushton Wakeling (4/7) Sep 13 2013 Hmm, well, I just reinstalled GDC using make install-strip, rebuilt the ...
- Iain Buclaw (8/15) Sep 13 2013 programs in question and they're still coming out as 12 MB ...
- Joseph Rushton Wakeling (6/7) Sep 13 2013 bin/gdc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV)...
- Iain Buclaw (10/18) Sep 13 2013 du -h lib64/libgphobos2.a
- Dicebot (5/10) Sep 15 2013 Well, looks like you have just found a bug in default Arch Linux
- Iain Buclaw (6/19) Sep 15 2013 --strip-debug should do the trick as well... --strip-unneeded
- Dicebot (4/26) Sep 15 2013 Well, with --strip-debug it is back to the original situation in
- Iain Buclaw (12/41) Sep 15 2013 --strip-unneeded could potentially cause lots of undefined reference
- Dicebot (3/13) Sep 15 2013 Ok, thanks.
- Iain Buclaw (8/22) Sep 15 2013 As per my initial post, strip not being ran on the library after
- Dicebot (4/10) Sep 15 2013 As per my answer, those result are _with_ "--strip-debug" :P
- Iain Buclaw (7/17) Sep 15 2013 If the size of the library is 70MB+ then it most certainly isn't
- Dicebot (3/7) Sep 15 2013 It is 18Mb (you are probably mixing my posts with Joseph ones,
- Iain Buclaw (5/12) Sep 15 2013 Stop renaming yourself between Dicebot and Joseph then! :o)
- Joseph Rushton Wakeling (2/3) Sep 16 2013 Flee, flee! Our secret identities have been revealed! :-O
- Iain Buclaw (7/17) Sep 15 2013 gdc's druntime also pulls in libgcc so that will be one factor to a
- Iain Buclaw (9/45) Sep 15 2013 Just tested on my system,
- Joseph Rushton Wakeling (4/9) Sep 13 2013 Ahh, OK.
- David Nadlinger (11/14) Sep 15 2013 LDC does not strip the library into a release build and debugging
- David Nadlinger (4/5) Sep 15 2013 s/strip/split/
- Iain Buclaw (5/9) Sep 15 2013 I knew what you meant. :o)
- Joseph Rushton Wakeling (4/7) Sep 13 2013 I ask because I just tried compiling with the -fdata-sections and
- Johannes Pfau (12/35) Sep 13 2013 It seems like the gdc compiled program has more symbols for some
- Dicebot (9/19) Sep 13 2013 Yep and `--gc-sections` gets it down to:
I was experimenting with `--gc-sections` effect on D code (with
great results) and have noticed that GDC binaries are much bigger
than DMD ones. I do understand that it is not a priority goal
right now but still curious, does anyone know what makes such
notable (~50%) difference?
(64-bit OS)
--------
import std.stdio, std.algorithm;
void main()
{
auto arr = [ 1, 2, 3 ];
writeln( arr.map!( a => a*2 )() );
}
--------
$ gdc -ofhello-gdc -O3 hello.d
$ dmd -ofhello-dmd -release -inline -O hello.d
$ ls -la
-rwxr-xr-x 1 dicebot users 819647 Sep 13 13:38 hello-dmd
-rwxr-xr-x 1 dicebot users 1386355 Sep 13 13:39 hello-gdc
-------
Sep 13 2013
On 13/09/13 13:45, Dicebot wrote:I was experimenting with `--gc-sections` effect on D code (with great results)Can you expand on this? Never heard of it before and can't find it in gdc --help or manpages.
Sep 13 2013
On Friday, 13 September 2013 at 11:58:53 UTC, Joseph Rushton Wakeling wrote:On 13/09/13 13:45, Dicebot wrote:`--gc-sections` is ld flag that enabled garbage collection of unreferenced sections in resulting binary. For it to work gcc/gdc need to be run with `-fdata-sections`and `-ffunction-sections` placing each symbol into own section. That will, for example, remove template function bodies that got inlined for all calls. For template-heavy code with good inliner it can reduce binary sizes tremendously (running it on snippet from this topic will reduce gdc binary size to almost match dmd one).I was experimenting with `--gc-sections` effect on D code (with great results)Can you expand on this? Never heard of it before and can't find it in gdc --help or manpages.
Sep 13 2013
On 13/09/13 14:02, Dicebot wrote:`--gc-sections` is ld flag that enabled garbage collection of unreferenced sections in resulting binary. For it to work gcc/gdc need to be run with `-fdata-sections`and `-ffunction-sections` placing each symbol into own section. That will, for example, remove template function bodies that got inlined for all calls. For template-heavy code with good inliner it can reduce binary sizes tremendously (running it on snippet from this topic will reduce gdc binary size to almost match dmd one).Ahh, OK. Related query -- is there any way of telling the compiler (gdc/gdmd or preferably any of the D compilers) to strip out unused symbols/functions/data from the binary? I have a module that includes a quite large array of immutable data (used for test purposes), but when this is compiled in with other code it adds about 10MB (!) to the executable size, even when the executable never uses it. It'd be nice to be able to strip that out automatically rather than having to tweak the build script manually to leave out that module -- it's so much simpler to have the Makefile simply build using the whole library source. [*] [* Yes, yes, I know, I should abandon Make and sort out a decent built system at long last ...]
Sep 13 2013
On Friday, 13 September 2013 at 13:14:49 UTC, Joseph Rushton Wakeling wrote:Ahh, OK. Related query -- is there any way of telling the compiler (gdc/gdmd or preferably any of the D compilers) to strip out unused symbols/functions/data from the binary? I have a module that includes a quite large array of immutable data (used for test purposes), but when this is compiled in with other code it adds about 10MB (!) to the executable size, even when the executable never uses it.It is exactly what `gdc -fdata-sections -Xlinker --gc-sections app.d` will do. Be careful though, if you use dynamic loading of shared libraries (or build your app as library) that may result in weird stuff when applied to all sources :)
Sep 13 2013
"Dicebot" <public dicebot.lv> On Friday, 13 September 2013 at 13:25:03 UTC, Dicebot wrote:It is exactly what `gdc -fdata-sections -Xlinker --gc-sections app.d` will do. Be careful though, if you use dynamic loading of shared libraries (or build your app as library) that may result in weird stuff when applied to all sources :)On my machine: ----- $ cat a.d immutable long[100_000] arr = 1; void main() { } ---- $ gdc -O3 a.d $ ls -la -rwxr-xr-x 1 dicebot users 1276934 Sep 13 15:21 a.out ---- $ gdc -O3 -fdata-sections a.d -Xlinker --gc-sections $ ls -la -rwxr-xr-x 1 dicebot users 434859 Sep 13 15:21 a.out ----
Sep 13 2013
On 13/09/13 15:25, Dicebot wrote:On Friday, 13 September 2013 at 13:14:49 UTC, Joseph Rushton Wakeling wrote:Tried it. It reduces 12 MB executables to 11 MB -- but if I manually exclude the module responsible for the big data, executable sizes fall to 2 MB.Related query -- is there any way of telling the compiler (gdc/gdmd or preferably any of the D compilers) to strip out unused symbols/functions/data from the binary? I have a module that includes a quite large array of immutable data (used for test purposes), but when this is compiled in with other code it adds about 10MB (!) to the executable size, even when the executable never uses it.It is exactly what `gdc -fdata-sections -Xlinker --gc-sections app.d` will do.
Sep 13 2013
On Friday, 13 September 2013 at 13:36:45 UTC, Joseph Rushton Wakeling wrote:Tried it. It reduces 12 MB executables to 11 MB -- but if I manually exclude the module responsible for the big data, executable sizes fall to 2 MB.Then it is likely to be marked as referenced by something :( Can you try to reduce this case? Would be interesting to investigate.
Sep 13 2013
On 13/09/13 15:36, Joseph Rushton Wakeling wrote:Tried it. It reduces 12 MB executables to 11 MB -- but if I manually exclude the module responsible for the big data, executable sizes fall to 2 MB.Sorry, I'm talking nonsense. I managed to accidentally build using ldmd2, which was responsible for the small executable sizes. The +10 MB executable size seems to be entirely down to gdc.
Sep 13 2013
On 13 September 2013 14:42, Joseph Rushton Wakeling <joseph.wakeling webdrake.net> wrote:On 13/09/13 15:36, Joseph Rushton Wakeling wrote:I expect this is because the phobos/druntime libraries shipped with dmd are (a) without debugging symbols and (b) stripped. If you were to strip libphobos after installing gdc, then you would see a significant drop in size. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';Tried it. It reduces 12 MB executables to 11 MB -- but if I manually exclude the module responsible for the big data, executable sizes fall to 2 MB.Sorry, I'm talking nonsense. I managed to accidentally build using ldmd2, which was responsible for the small executable sizes. The +10 MB executable size seems to be entirely down to gdc.
Sep 13 2013
On 13 September 2013 16:24, Iain Buclaw <ibuclaw ubuntu.com> wrote:On 13 September 2013 14:42, Joseph Rushton Wakeling <joseph.wakeling webdrake.net> wrote:In this way, I'd also expect those who build gdc from source would have large executables than those who install gdc through a package manager/installer. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';On 13/09/13 15:36, Joseph Rushton Wakeling wrote:I expect this is because the phobos/druntime libraries shipped with dmd are (a) without debugging symbols and (b) stripped. If you were to strip libphobos after installing gdc, then you would see a significant drop in size.Tried it. It reduces 12 MB executables to 11 MB -- but if I manually exclude the module responsible for the big data, executable sizes fall to 2 MB.Sorry, I'm talking nonsense. I managed to accidentally build using ldmd2, which was responsible for the small executable sizes. The +10 MB executable size seems to be entirely down to gdc.
Sep 13 2013
Am Fri, 13 Sep 2013 16:25:47 +0100 schrieb Iain Buclaw <ibuclaw ubuntu.com>:On 13 September 2013 16:24, Iain Buclaw <ibuclaw ubuntu.com> wrote: In this way, I'd also expect those who build gdc from source would have large executables than those who install gdc through a package manager/installer.The example from the original post is still valid though. Even with a stripped libphobos the executable produced by gdc is almost twice as big. ls -lh /usr/lib | grep phobos -rw-r--r-- 1 root root 18M 7. Sep 03:15 libgphobos2.a -rw-r--r-- 1 root root 12M 7. Sep 03:42 liblphobos.a -rw-r--r-- 1 root root 13M 7. Sep 03:42 liblphobos-debug.a -rw-r--r-- 1 root root 30M 25. Aug 19:08 libphobos2.a
Sep 13 2013
On 13/09/13 17:24, Iain Buclaw wrote:I expect this is because the phobos/druntime libraries shipped with dmd are (a) without debugging symbols and (b) stripped. If you were to strip libphobos after installing gdc, then you would see a significant drop in size.Could be. I do build with the --enable-checking=release option, what else do I need to do ... ?
Sep 13 2013
Am Fri, 13 Sep 2013 18:10:24 +0200 schrieb Joseph Rushton Wakeling <joseph.wakeling webdrake.net>:On 13/09/13 17:24, Iain Buclaw wrote:Use make install-strip instead of "make install"I expect this is because the phobos/druntime libraries shipped with dmd are (a) without debugging symbols and (b) stripped. If you were to strip libphobos after installing gdc, then you would see a significant drop in size.Could be. I do build with the --enable-checking=release option, what else do I need to do ... ?
Sep 13 2013
On 13/09/13 18:30, Johannes Pfau wrote:Use make install-strip instead of "make install"Hmm, well, I just reinstalled GDC using make install-strip, rebuilt the programs in question and they're still coming out as 12 MB ... Could it be static vs. shared druntime/Phobos?
Sep 13 2013
On Sep 13, 2013 5:41 PM, "Joseph Rushton Wakeling" < joseph.wakeling webdrake.net> wrote:On 13/09/13 18:30, Johannes Pfau wrote:programs in question and they're still coming out as 12 MB ...Use make install-strip instead of "make install"Hmm, well, I just reinstalled GDC using make install-strip, rebuilt theCould it be static vs. shared druntime/Phobos?Can you check if it in fact strips binaries? (you can check with 'file') Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 13 2013
On 13/09/13 19:22, Iain Buclaw wrote:Can you check if it in fact strips binaries? (you can check with 'file')bin/gdc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, stripped lib64/libgphobos2.a: current ar archive libgphobos2.a is 72 MB in size, while LDC breaks Phobos up into 2 parts, libphobos-ldc.a (20 MB) and libphobos-ldc-debug.a (33 MB).
Sep 13 2013
On 13 September 2013 18:28, Joseph Rushton Wakeling <joseph.wakeling webdrake.net> wrote:On 13/09/13 19:22, Iain Buclaw wrote:du -h lib64/libgphobos2.a 73M lib64/libgphobos2.a strip --strip-unneeded lib64/libgphobos2.a du -h lib64/libgphobos2.a 18M lib64/libgphobos2.a -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';Can you check if it in fact strips binaries? (you can check with 'file')bin/gdc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, stripped lib64/libgphobos2.a: current ar archive libgphobos2.a is 72 MB in size, while LDC breaks Phobos up into 2 parts, libphobos-ldc.a (20 MB) and libphobos-ldc-debug.a (33 MB).
Sep 13 2013
On Friday, 13 September 2013 at 18:09:15 UTC, Iain Buclaw wrote:du -h lib64/libgphobos2.a 73M lib64/libgphobos2.a strip --strip-unneeded lib64/libgphobos2.a du -h lib64/libgphobos2.a 18M lib64/libgphobos2.aWell, looks like you have just found a bug in default Arch Linux makepkg.conf :) It does only "--strip-debug" for static libraries (for unknown reasons I am trying to figure out). Thanks :)
Sep 15 2013
On 15 September 2013 20:46, Dicebot <public dicebot.lv> wrote:On Friday, 13 September 2013 at 18:09:15 UTC, Iain Buclaw wrote:--strip-debug should do the trick as well... --strip-unneeded probably isn't recommended for libraries. ;) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';du -h lib64/libgphobos2.a 73M lib64/libgphobos2.a strip --strip-unneeded lib64/libgphobos2.a du -h lib64/libgphobos2.a 18M lib64/libgphobos2.aWell, looks like you have just found a bug in default Arch Linux makepkg.conf :) It does only "--strip-debug" for static libraries (for unknown reasons I am trying to figure out). Thanks :)
Sep 15 2013
On Sunday, 15 September 2013 at 19:59:48 UTC, Iain Buclaw wrote:On 15 September 2013 20:46, Dicebot <public dicebot.lv> wrote:Well, with --strip-debug it is back to the original situation in the very first comment, numbers there are with --strip-debug (what is the potential danger with --strip-unneeded?)On Friday, 13 September 2013 at 18:09:15 UTC, Iain Buclaw wrote:--strip-debug should do the trick as well... --strip-unneeded probably isn't recommended for libraries. ;)du -h lib64/libgphobos2.a 73M lib64/libgphobos2.a strip --strip-unneeded lib64/libgphobos2.a du -h lib64/libgphobos2.a 18M lib64/libgphobos2.aWell, looks like you have just found a bug in default Arch Linux makepkg.conf :) It does only "--strip-debug" for static libraries (for unknown reasons I am trying to figure out). Thanks :)
Sep 15 2013
On 15 September 2013 21:02, Dicebot <public dicebot.lv> wrote:On Sunday, 15 September 2013 at 19:59:48 UTC, Iain Buclaw wrote:--strip-unneeded could potentially cause lots of undefined reference errors on static libraries. Shared libraries don't suffer this because symbols are put into a special section which strip knows not to touch. General rule of them: binaries: strip <file> static libraries: strip --strip-debug <file> shared libraries: strip --strip-unneeded <file> -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';On 15 September 2013 20:46, Dicebot <public dicebot.lv> wrote:Well, with --strip-debug it is back to the original situation in the very first comment, numbers there are with --strip-debug (what is the potential danger with --strip-unneeded?)On Friday, 13 September 2013 at 18:09:15 UTC, Iain Buclaw wrote:--strip-debug should do the trick as well... --strip-unneeded probably isn't recommended for libraries. ;)du -h lib64/libgphobos2.a 73M lib64/libgphobos2.a strip --strip-unneeded lib64/libgphobos2.a du -h lib64/libgphobos2.a 18M lib64/libgphobos2.aWell, looks like you have just found a bug in default Arch Linux makepkg.conf :) It does only "--strip-debug" for static libraries (for unknown reasons I am trying to figure out). Thanks :)
Sep 15 2013
On Sunday, 15 September 2013 at 21:05:18 UTC, Iain Buclaw wrote:--strip-unneeded could potentially cause lots of undefined reference errors on static libraries. Shared libraries don't suffer this because symbols are put into a special section which strip knows not to touch. General rule of them: binaries: strip <file> static libraries: strip --strip-debug <file> shared libraries: strip --strip-unneeded <file>Ok, thanks. What may cause twice the difference in the original post then? :)
Sep 15 2013
On 15 September 2013 22:07, Dicebot <public dicebot.lv> wrote:On Sunday, 15 September 2013 at 21:05:18 UTC, Iain Buclaw wrote:As per my initial post, strip not being ran on the library after installation. :-) The makefile for libphobos/libdruntime certainly doesn't strip the libraries for you when you make strip-install. At least not yet... -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';--strip-unneeded could potentially cause lots of undefined reference errors on static libraries. Shared libraries don't suffer this because symbols are put into a special section which strip knows not to touch. General rule of them: binaries: strip <file> static libraries: strip --strip-debug <file> shared libraries: strip --strip-unneeded <file>Ok, thanks. What may cause twice the difference in the original post then? :)
Sep 15 2013
On Sunday, 15 September 2013 at 21:30:17 UTC, Iain Buclaw wrote:As per my initial post, strip not being ran on the library after installation. :-) The makefile for libphobos/libdruntime certainly doesn't strip the libraries for you when you make strip-install. At least not yet...As per my answer, those result are _with_ "--strip-debug" :P (stripping is done automatically by package manager utilities like `makepkg` when you build package in Arch)
Sep 15 2013
On 15 September 2013 23:01, Dicebot <public dicebot.lv> wrote:On Sunday, 15 September 2013 at 21:30:17 UTC, Iain Buclaw wrote:If the size of the library is 70MB+ then it most certainly isn't running --strip-debug on the library. I can guarantee you at least this. :-) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';As per my initial post, strip not being ran on the library after installation. :-) The makefile for libphobos/libdruntime certainly doesn't strip the libraries for you when you make strip-install. At least not yet...As per my answer, those result are _with_ "--strip-debug" :P (stripping is done automatically by package manager utilities like `makepkg` when you build package in Arch)
Sep 15 2013
On Sunday, 15 September 2013 at 22:30:11 UTC, Iain Buclaw wrote:If the size of the library is 70MB+ then it most certainly isn't running --strip-debug on the library. I can guarantee you at least this. :-)It is 18Mb (you are probably mixing my posts with Joseph ones, they are unrelated)
Sep 15 2013
On 15 September 2013 23:48, Dicebot <public dicebot.lv> wrote:On Sunday, 15 September 2013 at 22:30:11 UTC, Iain Buclaw wrote:Stop renaming yourself between Dicebot and Joseph then! :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';If the size of the library is 70MB+ then it most certainly isn't running --strip-debug on the library. I can guarantee you at least this. :-)It is 18Mb (you are probably mixing my posts with Joseph ones, they are unrelated)
Sep 15 2013
On 16/09/13 01:03, Iain Buclaw wrote:Stop renaming yourself between Dicebot and Joseph then! :o)Flee, flee! Our secret identities have been revealed! :-O
Sep 16 2013
On 15 September 2013 23:01, Dicebot <public dicebot.lv> wrote:On Sunday, 15 September 2013 at 21:30:17 UTC, Iain Buclaw wrote:gdc's druntime also pulls in libgcc so that will be one factor to a larger executable. Having a look at ldd output, the gdc produced binary also links in libm, whereas dmd's doesn't. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';As per my initial post, strip not being ran on the library after installation. :-) The makefile for libphobos/libdruntime certainly doesn't strip the libraries for you when you make strip-install. At least not yet...As per my answer, those result are _with_ "--strip-debug" :P (stripping is done automatically by package manager utilities like `makepkg` when you build package in Arch)
Sep 15 2013
On 15 September 2013 22:05, Iain Buclaw <ibuclaw ubuntu.com> wrote:On 15 September 2013 21:02, Dicebot <public dicebot.lv> wrote:Just tested on my system, original size = 74240. strip-debug size = 17800. strip-unneeded size = 17448. So --strip-debug should is sufficient in reducing binary sizes. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';On Sunday, 15 September 2013 at 19:59:48 UTC, Iain Buclaw wrote:--strip-unneeded could potentially cause lots of undefined reference errors on static libraries. Shared libraries don't suffer this because symbols are put into a special section which strip knows not to touch.On 15 September 2013 20:46, Dicebot <public dicebot.lv> wrote:Well, with --strip-debug it is back to the original situation in the very first comment, numbers there are with --strip-debug (what is the potential danger with --strip-unneeded?)On Friday, 13 September 2013 at 18:09:15 UTC, Iain Buclaw wrote:--strip-debug should do the trick as well... --strip-unneeded probably isn't recommended for libraries. ;)du -h lib64/libgphobos2.a 73M lib64/libgphobos2.a strip --strip-unneeded lib64/libgphobos2.a du -h lib64/libgphobos2.a 18M lib64/libgphobos2.aWell, looks like you have just found a bug in default Arch Linux makepkg.conf :) It does only "--strip-debug" for static libraries (for unknown reasons I am trying to figure out). Thanks :)
Sep 15 2013
On 13/09/13 20:09, Iain Buclaw wrote:du -h lib64/libgphobos2.a 73M lib64/libgphobos2.a strip --strip-unneeded lib64/libgphobos2.a du -h lib64/libgphobos2.a 18M lib64/libgphobos2.aAhh, OK. Is there any way in which to ensure that the build splits Phobos up into library and debugging symbols à la LDC? Could be useful, no?
Sep 13 2013
On Friday, 13 September 2013 at 19:48:12 UTC, Joseph Rushton Wakeling wrote:Is there any way in which to ensure that the build splits Phobos up into library and debugging symbols à la LDC? Could be useful, no?LDC does not strip the library into a release build and debugging symbols (yet) – the '-debug' version just contains a debug build (i.e. with assertions and debug info enabled) of the standard library. Whether this is the best idea going forward can certainly be discussed (considering that the user most probably doesn't expect to get a non-optimized build of the standard library when using -g). David
Sep 15 2013
On Sunday, 15 September 2013 at 21:52:29 UTC, David Nadlinger wrote:LDC does not strip the library intos/strip/split/ David
Sep 15 2013
On 16 September 2013 00:15, David Nadlinger <code klickverbot.at> wrote:On Sunday, 15 September 2013 at 21:52:29 UTC, David Nadlinger wrote:I knew what you meant. :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';LDC does not strip the library intos/strip/split/
Sep 15 2013
On 13/09/13 15:14, Joseph Rushton Wakeling wrote:Related query -- is there any way of telling the compiler (gdc/gdmd or preferably any of the D compilers) to strip out unused symbols/functions/data from the binary?I ask because I just tried compiling with the -fdata-sections and -ffunction-sections options enabled, and the binaries I got were still including that lovely 10MB bonus ... :-P
Sep 13 2013
Am Fri, 13 Sep 2013 13:45:58 +0200
schrieb "Dicebot" <public dicebot.lv>:
I was experimenting with `--gc-sections` effect on D code (with
great results) and have noticed that GDC binaries are much bigger
than DMD ones. I do understand that it is not a priority goal
right now but still curious, does anyone know what makes such
notable (~50%) difference?
(64-bit OS)
--------
import std.stdio, std.algorithm;
void main()
{
auto arr = [ 1, 2, 3 ];
writeln( arr.map!( a => a*2 )() );
}
--------
$ gdc -ofhello-gdc -O3 hello.d
$ dmd -ofhello-dmd -release -inline -O hello.d
$ ls -la
-rwxr-xr-x 1 dicebot users 819647 Sep 13 13:38 hello-dmd
-rwxr-xr-x 1 dicebot users 1386355 Sep 13 13:39 hello-gdc
-------
It seems like the gdc compiled program has more symbols for some
reason:
----------
nm hello-dmd --defined-only | wc -l
3834
nm hello-gdc --defined-only | wc -l
5451
----------
Here's a "diff" of the defined symbols:
https://gist.github.com/jpf91/6550247
Sep 13 2013
On Friday, 13 September 2013 at 12:51:13 UTC, Johannes Pfau wrote:It seems like the gdc compiled program has more symbols for some reason: ---------- nm hello-dmd --defined-only | wc -l 3834 nm hello-gdc --defined-only | wc -l 5451 ---------- Here's a "diff" of the defined symbols: https://gist.github.com/jpf91/6550247Yep and `--gc-sections` gets it down to: ``` $ nm hello-gdc --defined-only | wc -l 3894 ``` I was curious though what kind of code gen optimization dmd uses here (as opposed to gdc) as simple experiments show that it does not remove unused template instances.
Sep 13 2013