On Friday, 20 September 2013 at 16:20:34 UTC, Duke Normandin wrote:
> I'm re-visiting the D language. I've compared the file sizes of 2 executables - 1 is compiled C code using gcc; the other is D code using dmd.
>
> helloWorld.d => helloWorld.exe = 146,972 bytes
> ex1hello.c => ex1-hello.exe = 5,661 bytes
>
> Why such a huge difference???
>
> Duke

That 140KB is called the CYA document.  It is there so that when you the programmer screws up you don't look so bad in front of your boss.

On Friday, 20 September 2013 at 17:26:29 UTC, Duke Normandin wrote:
> Now that I know _why_ , is there a way to shave tons off those executables? Any optimization possible?

Yes, you can get D programs down very small - I've gone as low as 3 KB before on Linux (100% statically linked, doesn't even depend on the C runtime), where the executables are generally a little larger than on Windows.

BUT, the runtime code is there for a reason. Stripping it out means you lose D features, can't use most D libraries, and have to know druntime's implementation fairly well.

So it isn't something you really want to do.


Why is size important to you though? 140 KB really isn't bad, and will probably shrink to a small percentage of the total once you write a real program that's more than just hello world.

On Friday, 20 September 2013 at 17:27:56 UTC, captaindet wrote:
> i have a short program using GtkD. the exe is

gtkd's size is one reason why I started writing minigui.d. It isn't finished yet, but the resulting exes are about 220 KB instead of 2MB!

On Friday, 20 September 2013 at 17:27:30 UTC, Duke Normandin wrote:
> On Friday, 20-Sep-13 10:50 AM, Temtaime wrote:
>> C/C++ applications also carries on its runtime(mingwm10, msvc's
>> redist, for example).
>> If compiled with static runtime, msvc's hello world application uses
>> about 40 KB.
>
> +1

I don't think that static runtime comes with a garbage collector either nor does it come with a lot of other really nice features that come with D auto-magically.  I remember these same questions being brought up with C being compared to Assembly, Visual Basic vs GWBASIC, COBOL vs FORTRAN vs RPG vs C.  This discussion always comes up over and over again in the programming world.  Those of us that have come to D is not coming here because of the size of the executable compared to <your fav. language here>.  We came because D is fast, robust, easy to maintain, easy to understand, and just an all around practical language.  Duke unless your trying to build programs for embedded appliances I don't think this question really matters much in this day and age with Terabyte hard drives and gigabytes of ram on the modern computer.  Back when C was built we only had 64KB to work with so we could not have garbage collection, thread libraries, or even a string library built into the compiler.  IMHO who cares as long as it is reasonable and necessary to make time to market quicker and still produce a sound product.  In the end ask yourself what is 100KB to make your life as a programmer easier.

On Friday, 20 September 2013 at 16:40:48 UTC, Justin Whear wrote:
> On Fri, 20 Sep 2013 18:35:39 +0200, Temtaime wrote:
>
>> DMD likes the size.
>> When compiling, compiler may use GBs of RAM.
>> In resulting executable there is no dead/unused code elimination.
>
> http://imgur.com/W5AMy0P

Ha, awesome! Swiped for future use. ;)

On Friday, 20 September 2013 at 18:09:03 UTC, Adam D. Ruppe wrote:
> On Friday, 20 September 2013 at 17:27:56 UTC, captaindet wrote:
>> i have a short program using GtkD. the exe is
>
> gtkd's size is one reason why I started writing minigui.d. It isn't finished yet, but the resulting exes are about 220 KB instead of 2MB!

Please share minigui.d with us?

On Friday, 20 September 2013 at 18:37:36 UTC, JohnnyK wrote:
> Please share minigui.d with us?

it is on my misc. github:

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

you'll need color.d, simpledisplay.d, and minigui.d

There's still a lot of work that has to be done to finish minigui.d's widget classes, so it isn't really usable yet except for some very simple things.

The main question is how topicstarter achieved 150 KB, is it on linux?

I have 137 KB with DMD when compiling

import core.stdc.stdio;
void main() { printf(`hello world`); }

And 673 KB when using writeln from std.stdio.

I'm using DMD 2.063.2 on windows.


You're saying about terabytes hdd and gigabytes ram..
This is not right way when developing the software. Software MUST running almost ANYWHERE and consumes minimal resources.

For example i hate 3dsmax developers when on my game's map it uses several GB of ram amd freezes sometimes, when Blender uses only 500 MB and runs fast. The only reason for me for use 3dsmax is more friendly contoling. But this is another story...

Some users which doesn't have ""modern"" PC will hate your app too i think.
One should optimize ALL things which he can to optimize.

Staying on the topic i need say that it's possible to reduce executable size.
For example, as David says, GCC produces 700 KB for hello world. There is TCC(Tiny C Compiler). It produces hello executable of 2 KB. It's really nice C compiler, i respect its developers.

C++ also has threads and oter things you said.
For example, DMD's compiler size is about 1.6 MB. It is large and sophisticated. Nuff said.

On Fri, Sep 20, 2013 at 11:26:18AM -0600, Duke Normandin wrote:
> On Friday, 20-Sep-13 10:45 AM, Adam D. Ruppe wrote:
> >On Friday, 20 September 2013 at 16:20:34 UTC, Duke Normandin wrote:
> >>Why such a huge difference???
> >
> >The D program carries its additional D runtime library code with it, whereas the C program only depends on libraries provided by the operating system, and thus it doesn't have to include it in the exe.
> 
> Now that I know _why_ , is there a way to shave tons off those executables? Any optimization possible?

If you're on Linux:

	dmd -release -O myprogram.d
	strip myprogram
	upx myprogram

I've seen this reduce a 50MB executable down to about 400k. YMMV.

Keep in mind, though, that stripping basically deletes all debugging information from the executable (plus a bunch of other stuff -- you don't want to do this to an object file or a library, for example), so it's not something you want to do during development. And upx turns your executable into something that probably violates the ELF spec in many different ways, but resembles it closely enough that the kernel will still run it. File type recognizers like 'file' may fail to recognize the result as an executable afterwards. But it will still work. (That's how cool upx is, in case you don't already know that.)


T

-- 
The right half of the brain controls the left half of the body. This means that only left-handed people are in their right mind. -- Manoj Srivastava

On Fri, 20 Sep 2013 21:45:48 +0200
"Temtaime" <temtaime@gmail.com> wrote:
> 
> Software MUST running almost ANYWHERE and consumes minimal resources.
> 
> For example i hate 3dsmax developers when on my game's map it uses several GB of ram amd freezes sometimes, when Blender uses only 500 MB and runs fast. The only reason for me for use 3dsmax is more friendly contoling. But this is another story...
> 
> Some users which doesn't have ""modern"" PC will hate your app
> too i think.
> One should optimize ALL things which he can to optimize.
> 

I agree with what you're saying here, but the problem is we're looking at a difference of only a few hundred k.

Heck, my primary PC was a 32-bit single-core right up until last year (and I still use it as a secondary system), and I didn't care one bit if a hello world was 1k or 1MB.

How many real world programs are as trivial as a hello world? A few maybe, but not many. Certainly not enough to actually add up to anything significant, unless maybe you happen to be running on a 286 or such.

If we were talking about real-world D programs taking tens/hundreds of
MB more than they should, then that would be a problem. But they
don't. We're just talking about a few hundred k for an *entire* program.