• jovo (7/7) Dec 18 2010 Hi,
• Nick Sabalausky (4/11) Dec 18 2010 Yes. The runtime is currently built into the exe. With C/C++, the runtim...
• jovo (2/8) Dec 18 2010 Thanks!
• BLS (2/14) Dec 18 2010 Jovo compared d1 vs d2.. and here the difference is significant.
• Jacob Carlborg (6/18) Dec 18 2010 Building the D runtime and the standard library as a dynamic library
• torhu (7/14) Dec 18 2010 I'm guessing the new version of std.random pulls in almost all of the
• Gary Whatmore (3/11) Dec 19 2010 This is something you shouldn't worry too much about. Hard drives and sy...
• Steven Schveighoffer (12/25) Dec 20 2010 I hate this excuse, it's used all the time. The reality is that
• Andrej Mitrovic (8/11) Dec 20 2010 Smaller programs, as in *less code*? Yes. But I really doubt that an
• Steven Schveighoffer (9/18) Dec 20 2010 No, I mean smaller exe size. It's well known that shrinking an app so
• Jacob Carlborg (7/34) Dec 20 2010 One problem that seems hard to solve in a good way is the module
• Steven Schveighoffer (18/49) Dec 20 2010 This is definitely a problem. The issue I see mostly here is that Tango...

jovo <jovo at.home> writes:

Hi,
Today I compiled my old two module console program with d-2.50.
It uses only std.c.time, std.c.stdio, std.random and templates.
Compiled with -O -release, on windows.
Executable size (d-2.50): 4.184 kb. 
Trayed with d-1.30: 84 kb.

Is it expected?

"Nick Sabalausky" <a a.a> writes:

"jovo" <jovo at.home> wrote in message news:ieit9a$2n58$1 digitalmars.com...
 Hi,
 Today I compiled my old two module console program with d-2.50.
 It uses only std.c.time, std.c.stdio, std.random and templates.
 Compiled with -O -release, on windows.
 Executable size (d-2.50): 4.184 kb.
 Trayed with d-1.30: 84 kb.

 Is it expected?

Yes. The runtime is currently built into the exe. With C/C++, the runtime is 
often stored separately so the exe files themseves end up a lot smaller, 
even though they rely on at least as much compiled code.

jovo <jovo at.home> writes:

Nick Sabalausky Wrote:

 
 Yes. The runtime is currently built into the exe. With C/C++, the runtime is 
 often stored separately so the exe files themseves end up a lot smaller, 
 even though they rely on at least as much compiled code.
 
 

Thanks!

BLS <windevguy hotmail.de> writes:

On 18/12/2010 19:25, Nick Sabalausky wrote:
 "jovo"<jovo at.home>  wrote in message news:ieit9a$2n58$1 digitalmars.com...
 Hi,
 Today I compiled my old two module console program with d-2.50.
 It uses only std.c.time, std.c.stdio, std.random and templates.
 Compiled with -O -release, on windows.
 Executable size (d-2.50): 4.184 kb.
 Trayed with d-1.30: 84 kb.

 Is it expected?

 Yes. The runtime is currently built into the exe. With C/C++, the runtime is
 often stored separately so the exe files themseves end up a lot smaller,
 even though they rely on at least as much compiled code.

Jovo compared d1 vs d2.. and here the difference is significant.

Jacob Carlborg <doob me.com> writes:

On 2010-12-18 19:25, Nick Sabalausky wrote:
 "jovo"<jovo at.home>  wrote in message news:ieit9a$2n58$1 digitalmars.com...
 Hi,
 Today I compiled my old two module console program with d-2.50.
 It uses only std.c.time, std.c.stdio, std.random and templates.
 Compiled with -O -release, on windows.
 Executable size (d-2.50): 4.184 kb.
 Trayed with d-1.30: 84 kb.

 Is it expected?

 Yes. The runtime is currently built into the exe. With C/C++, the runtime is
 often stored separately so the exe files themseves end up a lot smaller,
 even though they rely on at least as much compiled code.

Building the D runtime and the standard library as a dynamic library 
will get you the same executable size as a C executable, at least with 
D1 and Tango on Mac OS X.

-- 
/Jacob Carlborg

torhu <no spam.invalid> writes:

On 18.12.2010 19:07, jovo wrote:
 Hi,
 Today I compiled my old two module console program with d-2.50.
 It uses only std.c.time, std.c.stdio, std.random and templates.
 Compiled with -O -release, on windows.
 Executable size (d-2.50): 4.184 kb.
 Trayed with d-1.30: 84 kb.

 Is it expected?

I'm guessing the new version of std.random pulls in almost all of the 
rest of phobos, directly or indirectly.  This is common throughout 
phobos, and means that if you want a small executable, you have to stick 
with basically just the C core.c.* (or std.c.*) stuff.  Unless you want 
to custom build Phobos, of course...

If you really need a small executable, use Tango instead of Phobos.

Gary Whatmore <no spam.sp> writes:

jovo Wrote:

 Hi,
 Today I compiled my old two module console program with d-2.50.
 It uses only std.c.time, std.c.stdio, std.random and templates.
 Compiled with -O -release, on windows.
 Executable size (d-2.50): 4.184 kb. 
 Trayed with d-1.30: 84 kb.
 
 Is it expected?

This is something you shouldn't worry too much about. Hard drives and system
memory are getting bigger. 4 megabytes isn't that much when you have soon 4
terabytes of space. A single PC rarely has one million executables. So, keep
writing more code. That's what the space is for. 

 - G.W.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Sun, 19 Dec 2010 08:25:36 -0500, Gary Whatmore <no spam.sp> wrote:

 jovo Wrote:

 Hi,
 Today I compiled my old two module console program with d-2.50.
 It uses only std.c.time, std.c.stdio, std.random and templates.
 Compiled with -O -release, on windows.
 Executable size (d-2.50): 4.184 kb.
 Trayed with d-1.30: 84 kb.

 Is it expected?

 This is something you shouldn't worry too much about. Hard drives and  
 system memory are getting bigger. 4 megabytes isn't that much when you  
 have soon 4 terabytes of space. A single PC rarely has one million  
 executables. So, keep writing more code. That's what the space is for.

I hate this excuse, it's used all the time.  The reality is that  
executable size *does* matter, and it always will.  Smaller programs load  
and run faster.

The other reality is that this is a toolchain issue, and not a language or  
spec issue.  With improved tools, this gets better, so it's not worth  
worrying about now.  When D gets full shared-library support, this problem  
goes away.

Array appending performance/invalidity used to be one of the most common  
negatives cited on D.  Now, nobody talks about it because it's been  
fixed.  You will see the same thing with exe size once D uses shared libs.

-Steve

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 12/20/10, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 The reality is that
 executable size *does* matter, and it always will.  Smaller programs load
 and run faster.

Smaller programs, as in *less code*? Yes. But I really doubt that an
application with the *exact same code* is faster if it's executable
size shrinks. There are some apps that specialize in shrinking an
executable size, I know that.

I'd really like to see some performance comparisons of two copies of
the same app, one with the original exe size, and the other processed
by an exe shrinker.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Mon, 20 Dec 2010 12:28:10 -0500, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:

 On 12/20/10, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 The reality is that
 executable size *does* matter, and it always will.  Smaller programs  
 load
 and run faster.

 Smaller programs, as in *less code*? Yes. But I really doubt that an
 application with the *exact same code* is faster if it's executable
 size shrinks. There are some apps that specialize in shrinking an
 executable size, I know that.

No, I mean smaller exe size.  It's well known that shrinking an app so  
portions of it (or all of it) fits into the cache can increase performance.

If using common shared libraries, the OS only need load and store the  
library in memory once, so it can save memory and load more programs, or a  
program that consumes more memory during runtime can run faster without  
having to swap to disk.

-Steve

Jacob Carlborg <doob me.com> writes:

On 2010-12-20 18:10, Steven Schveighoffer wrote:
 On Sun, 19 Dec 2010 08:25:36 -0500, Gary Whatmore <no spam.sp> wrote:

 jovo Wrote:

 Hi,
 Today I compiled my old two module console program with d-2.50.
 It uses only std.c.time, std.c.stdio, std.random and templates.
 Compiled with -O -release, on windows.
 Executable size (d-2.50): 4.184 kb.
 Trayed with d-1.30: 84 kb.

 Is it expected?

 This is something you shouldn't worry too much about. Hard drives and
 system memory are getting bigger. 4 megabytes isn't that much when you
 have soon 4 terabytes of space. A single PC rarely has one million
 executables. So, keep writing more code. That's what the space is for.

 I hate this excuse, it's used all the time. The reality is that
 executable size *does* matter, and it always will. Smaller programs load
 and run faster.

 The other reality is that this is a toolchain issue, and not a language
 or spec issue. With improved tools, this gets better, so it's not worth
 worrying about now. When D gets full shared-library support, this
 problem goes away.

One problem that seems hard to solve in a good way is the module 
constructors. Currently on Mac OS X with Tango when it's built as a 
dynamic library all module constructors are run, regardless if they're 
imported or not.

 Array appending performance/invalidity used to be one of the most common
 negatives cited on D. Now, nobody talks about it because it's been
 fixed. You will see the same thing with exe size once D uses shared libs.

 -Steve


-- 
/Jacob Carlborg

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Mon, 20 Dec 2010 14:15:26 -0500, Jacob Carlborg <doob me.com> wrote:

 On 2010-12-20 18:10, Steven Schveighoffer wrote:
 On Sun, 19 Dec 2010 08:25:36 -0500, Gary Whatmore <no spam.sp> wrote:

 jovo Wrote:

 Hi,
 Today I compiled my old two module console program with d-2.50.
 It uses only std.c.time, std.c.stdio, std.random and templates.
 Compiled with -O -release, on windows.
 Executable size (d-2.50): 4.184 kb.
 Trayed with d-1.30: 84 kb.

 Is it expected?

 This is something you shouldn't worry too much about. Hard drives and
 system memory are getting bigger. 4 megabytes isn't that much when you
 have soon 4 terabytes of space. A single PC rarely has one million
 executables. So, keep writing more code. That's what the space is for.

 I hate this excuse, it's used all the time. The reality is that
 executable size *does* matter, and it always will. Smaller programs load
 and run faster.

 The other reality is that this is a toolchain issue, and not a language
 or spec issue. With improved tools, this gets better, so it's not worth
 worrying about now. When D gets full shared-library support, this
 problem goes away.

 One problem that seems hard to solve in a good way is the module  
 constructors. Currently on Mac OS X with Tango when it's built as a  
 dynamic library all module constructors are run, regardless if they're  
 imported or not.

This is definitely a problem.  The issue I see mostly here is that Tango  
has many modules, specifically to allow trimming of unused code (another  
toolchain issue).

Two solutions that might work:

1. Mark the root module of the application (i.e. the one with main()).   
Then only initialize modules that are depended on by that module.  Where  
this fails is modules who define extern(C) functions (such as druntime),  
since you do not have to import those modules in order to call the  
functions.  I suppose modules with extern(C) declarations must also be  
marked as required.
2. Split the library into smaller libraries that would only be used when  
needed.

I'm not sure Phobos would have so much of an issue, because the number of  
modules is less.

One thing is for sure, this problem would be easier solved if we could  
decide things at link-time...

-Steve