www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Runtime?

reply Wulfklaue <wulfklaue wulfklaue.com> writes:
A quick question. After watching the DLang 2017 conference, there 
was mention about the runtime optimizing that is going on. Will 
this have a impact on the default memory usage (on small projects 
)?
May 23 2017
parent reply Wulfklaue <wulfklaue wulfklaue.com> writes:
On Tuesday, 23 May 2017 at 15:36:45 UTC, Wulfklaue wrote:

 A quick question. After watching the DLang 2017 conference, 
 there was mention about the runtime optimizing that is going 
 on. Will this have a impact on the default memory usage (on 
 small projects )?


Why does even a simple empty:

void main()
{
while(true)
	{}
}
May 24 2017
parent reply Wulfklaue <wulfklaue wulfklaue.com> writes:
Great ... accidentally pressed send.

So my question was:

Why does even a simple empty empty statement like this, compiled 
with DMD, show under windows a almost 1.7MB memory usage?

void main()
{
   while(true){}
}

The same in C/C++ is simply 0.1MB. This is why i asked the 
question if the runtime is somehow responsible?
May 24 2017
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Wednesday, 24 May 2017 at 07:54:04 UTC, Wulfklaue wrote:

 Great ... accidentally pressed send.

 So my question was:

 Why does even a simple empty empty statement like this, 
 compiled with DMD, show under windows a almost 1.7MB memory 
 usage?


Because the garbage collector (GC) allocates a sizable chunk of 
memory from the operating system at program startup, from which 
it then in turn allocates memory for you when you use things like 
dynamic closures, `new XYZ`, etc.


 void main()
 {
   while(true){}
 }

 The same in C/C++ is simply 0.1MB. This is why i asked the 
 question if the runtime is somehow responsible?


Yes, it is. It is the price we have to pay for having a GC. If 
the overhead bothers you, you might want to compare it with other 
garbage collected languages (such as Go).

PS: This might belong in Learn, instead of General.
May 24 2017
next sibling parent reply Wulfklaue <wulfklaue wulfklaue.com> writes:
On Wednesday, 24 May 2017 at 10:34:02 UTC, Moritz Maxeiner wrote:

 Because the garbage collector (GC) allocates a sizable chunk of 
 memory from the operating system at program startup, from which 
 it then in turn allocates memory for you when you use things 
 like dynamic closures, `new XYZ`, etc.


Well, that sounds just silly.


 Yes, it is. It is the price we have to pay for having a GC. If 
 the overhead bothers you, you might want to compare it with 
 other garbage collected languages (such as Go).


Go is a different animal because of the concurrent GC.
May 24 2017
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 24 May 2017 at 14:26:42 UTC, Wulfklaue wrote:

 Well, that sounds just silly.


You can bypass it by doing an `extern(C)` main in D... but 
really, the 1 MB preallocation isn't much for small programs and 
for larger programs it will be used anyway, so you aren't 
actually losing anything.
May 24 2017
prev sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
On Wednesday, 24 May 2017 at 14:26:42 UTC, Wulfklaue wrote:

 On Wednesday, 24 May 2017 at 10:34:02 UTC, Moritz Maxeiner 
 wrote:

 Because the garbage collector (GC) allocates a sizable chunk 
 of memory from the operating system at program startup, from 
 which it then in turn allocates memory for you when you use 
 things like dynamic closures, `new XYZ`, etc.


 Well, that sounds just silly.


Before making such judgement you may want to consider the cost of 
system calls, how memory fragmentation affects a conservative GC, 
and why we cannot have a different kind of GC without 
unacceptable trade offs.


 Yes, it is. It is the price we have to pay for having a GC. If 
 the overhead bothers you, you might want to compare it with 
 other garbage collected languages (such as Go).


 Go is a different animal because of the concurrent GC.


Not the point.
May 24 2017
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/24/17 6:34 AM, Moritz Maxeiner wrote:

 On Wednesday, 24 May 2017 at 07:54:04 UTC, Wulfklaue wrote:

 Great ... accidentally pressed send.

 So my question was:

 Why does even a simple empty empty statement like this, compiled with
 DMD, show under windows a almost 1.7MB memory usage?


 Because the garbage collector (GC) allocates a sizable chunk of memory
 from the operating system at program startup, from which it then in turn
 allocates memory for you when you use things like dynamic closures, `new
 XYZ`, etc.


Note, you can usually allocate close to the entire address space, but if 
you never access it, it's not actually used in the RAM of your computer. 
So it's possible D is pre-allocating a bunch of space from the OS, but 
it's not actually consuming RAM.

However, I don't know the true answer. It may actually be 1.7MB of 
"bookeeping", but I doubt that. The GC structures aren't *that* large, 
I'd expect at most 10 pages for the small-chunk bins, and a few more for 
bits. Possibly the static segment is large, but 1.7 MB is around 400+ 
pages. It's likely that most of that is just a pre-allocation of a large 
continuous space "just in case", but it's not actually wired to RAM yet.

-Steve
May 24 2017
parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Wednesday, 24 May 2017 at 15:07:42 UTC, Steven Schveighoffer 
wrote:


 However, I don't know the true answer. It may actually be 1.7MB 
 of "bookeeping", but I doubt that...


It's a bit of pre-allocation and some internal bookkeeping.

void main()
{
     import std.stdio;
     import core.memory;
     writeln(GC.stats);
}

//   used, free
Stats(256, 1048320)

The remaining .7Mb could probably be attributed to some internal 
data structures.
May 24 2017
parent Wulfklaue <wulfklaue wulfklaue.com> writes:
On Wednesday, 24 May 2017 at 15:22:55 UTC, Stanislav Blinov wrote:

 It's a bit of pre-allocation and some internal bookkeeping.

 void main()
 {
     import std.stdio;
     import core.memory;
     writeln(GC.stats);
 }

 //   used, free
 Stats(256, 1048320)

 The remaining .7Mb could probably be attributed to some 
 internal data structures.


Thanks, it places D in a better limelight.

I assume that from the 0.7MB, part of it is the executable ( 
0.24MB ) that is loaded into memory.

+1 for the answer. :)
May 24 2017