On Tuesday, 31 March 2015 at 04:56:13 UTC, Daniel Murphy wrote:
> I've used D's GC with DDMD.  It works*, but you're trading better memory usage for worse allocation speed.  It's quite possible we could add a switch to ddmd to enable the GC.
>

That is not accurate. For small programs, yes. For anything non trivial, the amount of memory in the working is set become so big that I doubt there is any advantage of doing so.

"deadalnix"  wrote in message news:uwajsjgcjtzfeqtqoyjt@forum.dlang.org...

> On Tuesday, 31 March 2015 at 04:56:13 UTC, Daniel Murphy wrote:
> > I've used D's GC with DDMD.  It works*, but you're trading better memory usage for worse allocation speed.  It's quite possible we could add a switch to ddmd to enable the GC.
> >
>
> That is not accurate. For small programs, yes. For anything non trivial, the amount of memory in the working is set become so big that I doubt there is any advantage of doing so.

I don't see how it's inaccurate.  Many projects fit into the range where they do not exhaust physical memory, and the slower allocation speed can really hurt.

It's worth noting that 'small' doesn't mean low number of lines of code, but low number of instantiated templates and ctfe calls. 

On Tue, 31 Mar 2015 05:21:13 +0000, deadalnix wrote:

> On Tuesday, 31 March 2015 at 04:56:13 UTC, Daniel Murphy wrote:
>> I've used D's GC with DDMD.  It works*, but you're trading better memory usage for worse allocation speed.  It's quite possible we could add a switch to ddmd to enable the GC.
>>
>>
> That is not accurate. For small programs, yes. For anything non trivial, the amount of memory in the working is set become so big that I doubt there is any advantage of doing so.

i think that DDMD can start with GC turned off, and automatically turn it on when RAM consumption goes over 1GB, for example. this way small-sized (and even middle-sized) projects without heavy CTFE will still enjoy "nofree is fast" strategy, and big projects will not eat the whole box' RAM.

On Tuesday, 31 March 2015 at 05:42:02 UTC, ketmar wrote:
> i think that DDMD can start with GC turned off, and automatically turn it
> on when RAM consumption goes over 1GB, for example. this way small-sized
> (and even middle-sized) projects without heavy CTFE will still enjoy
> "nofree is fast" strategy, and big projects will not eat the whole box'
> RAM.

Recording the information necessary to free memory costs performance (and more memory) itself. With a basic bump-the-pointer scheme, you don't need to worry about page sizes or free lists or heap fragmentation - all allocated data is contiguous, there is no metadata, and you can't back out of that.

On 3/30/15 7:41 PM, Vladimir Panteleev wrote:
> On Monday, 30 March 2015 at 22:51:43 UTC, Andrei Alexandrescu wrote:
>> Part of our acceptance tests should be peak memory, object file size,
>> executable file size, and run time for building a few test programs
>> (starting with "hello, world"). Any change in these must be
>> investigated, justified, and documented. -- Andrei
>
> I have filed this issue today:
>
> https://issues.dlang.org/show_bug.cgi?id=14381

The current situation is a shame. I appreciate the free service we're getting, but sometimes you just can't afford the free stuff. -- Andrei

On Tue, 31 Mar 2015 05:57:45 +0000, Vladimir Panteleev wrote:

> On Tuesday, 31 March 2015 at 05:42:02 UTC, ketmar wrote:
>> i think that DDMD can start with GC turned off, and automatically turn
>> it on when RAM consumption goes over 1GB, for example. this way
>> small-sized (and even middle-sized) projects without heavy CTFE will
>> still enjoy "nofree is fast" strategy, and big projects will not eat
>> the whole box'
>> RAM.
> 
> Recording the information necessary to free memory costs performance (and more memory) itself. With a basic bump-the-pointer scheme, you don't need to worry about page sizes or free lists or heap fragmentation - all allocated data is contiguous, there is no metadata, and you can't back out of that.

TANSTAAFL. alas. yet without `free()` there aren't free lists to scan and so on, so it can be almost as fast as bump-the-pointer. the good thing is that user doesn't have to do the work that machine can do for him, i.e. thinking about how to invoke the compiler -- with GC or without GC.

"Vladimir Panteleev"  wrote in message news:remgknxogqlfwfnsubce@forum.dlang.org...

> Recording the information necessary to free memory costs performance (and more memory) itself. With a basic bump-the-pointer scheme, you don't need to worry about page sizes or free lists or heap fragmentation - all allocated data is contiguous, there is no metadata, and you can't back out of that.

It's possible that we could use a hybrid approach, where a GB or so is allocated from the GC in one chunk, then filled up using a bump-pointer allocator.  When that's exhausted, the GC can start being used as normal for the rest of the compilation.  The big chunk will obviously never be freed, but the GC still has a good chance to keep memory usage under control.  (on 64-bit at least) 

Is anyone there looked how msvc for example compiles really big files ?
I never seen it goes over 200 MB. And it is written in C++, so no GC. And compiles very quick.
I think DMD should be refactored and free the memory, pools and other techniques.

*use pools...

On 2015-03-31 01:28, w0rp wrote:

> I sometimes think DMD's memory should be... garbage collected. I used
> the forbidden phrase!

Doesn't DMD already have a GC that is disabled?

-- 
/Jacob Carlborg