September 01, 2014 Re: "If you used printf instead of writeln […]" [ignore previous post] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Abe | 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 |
September 01, 2014 Re: printf-based D code | ||||
---|---|---|---|---|
| ||||
Posted in reply to Abe | 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 |
September 01, 2014 Re: "-defaultlib=libphobos2" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | > 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 |
September 01, 2014 Re: "-defaultlib=libphobos2" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Abe | 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.
|
September 01, 2014 Re: why does DMD compile "hello world" to about 500 _kilobytes_ on Mac OS X [x86_64]?!? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Abe | 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 |
September 01, 2014 Re: Oh, and I almost forgot: does this problem exist on any other platforms too? … | ||||
---|---|---|---|---|
| ||||
Posted in reply to Abe | 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 |
September 01, 2014 Re: "The std.stdio package imports most the standard library" etc. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Abe | 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 |
September 01, 2014 Re: "-defaultlib=libphobos2" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Abe | 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 |
September 01, 2014 Re: "-defaultlib=libphobos2" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Joakim | 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.
|
September 01, 2014 Re: "-defaultlib=libphobos2" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Joakim | 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.
|
Copyright © 1999-2021 by the D Language Foundation