Hi,

Is it possible to switch off the GC entirely in D?
Can the GC be switched off completely - including within phobos?

What I am looking for is absolute control over memory management.
I've done some tests with GC on and GC off and the performance with GC is
not good enough for my requirements.

Thanks.
- Adrian.

On Saturday, 6 April 2013 at 04:16:13 UTC, Adrian Mercieca wrote:
> Hi,
>
> Is it possible to switch off the GC entirely in D?
> Can the GC be switched off completely - including within phobos?

import core.memory;
GC.disable();

However, most D code - including the runtime and standard library - assume that a GC is present, and thus may leak memory.

> What I am looking for is absolute control over memory management.
> I've done some tests with GC on and GC off and the performance with GC is
> not good enough for my requirements.

The GC will not be invoked unless you allocate memory (either explicitly, using "new", or using D's features which do so, such as dynamic arrays and closures). If you do not make use of those features, no GC code will run.

Thanks for your very quick answer Vladimir.

> On Saturday, 6 April 2013 at 04:16:13 UTC, Adrian Mercieca wrote:
>> Hi,
>>
>> Is it possible to switch off the GC entirely in D? Can the GC be switched off completely - including within phobos?
> 
> import core.memory;
> GC.disable();
> 
> However, most D code - including the runtime and standard library - assume that a GC is present, and thus may leak memory.

Guess that answers the question; even if I avoid the GC in my own code and disable it as you say, then the runtime and standard library will leak - rendering the whole thing as not-an-option.

So I'll either have to not use the runtime+standard libraries and implement all I'd need myself without GC or else stick to C++. The latter would be a pity because I really like D, but then in C++ I have full control and the performance is always good.

In my very simple test, the GC version of my program ran more than twice slower than the non GC version. I just cannot accept that kind of performance penalty.

Thanks.

On Saturday, 6 April 2013 at 08:01:09 UTC, Adrian Mercieca wrote:
> So I'll either have to not use the runtime+standard libraries and
> implement all I'd need myself without GC or else stick to C++. The latter
> would be a pity because I really like D, but then in C++ I have full
> control and the performance is always good.

It is actually even worse, as omitting runtime cripples core language noticably. I was hinted with this cool project though : https://bitbucket.org/timosi/minlibd

> In my very simple test, the GC version of my program ran more than twice
> slower than the non GC version. I just cannot accept that kind of
> performance penalty.

Raw performance is kind of achievable if you use own memory pools for data and limit GC only for language constructs (appending to slices, delegates etc.) - those to approaches can happily coexist in D.

Problems start when soft real-time requirements appear.

On Saturday, 6 April 2013 at 04:16:13 UTC, Adrian Mercieca wrote:
> Hi,
>
> Is it possible to switch off the GC entirely in D?
> Can the GC be switched off completely - including within phobos?
>
> What I am looking for is absolute control over memory management.
> I've done some tests with GC on and GC off and the performance with GC is
> not good enough for my requirements.

You can switch off the GC, but then things will leak as the core language, druntime, and phobos all use the GC is many cases.

What I do is just avoid the functions that allocate, and rewrite the ones I need. I also use a modified druntime that prints callstacks when a GC allocation occurs, so I know if it happens by accident.

Am 06.04.2013 10:01, schrieb Adrian Mercieca:
> Thanks for your very quick answer Vladimir.
>
>> On Saturday, 6 April 2013 at 04:16:13 UTC, Adrian Mercieca wrote:
>>> Hi,
>>>
>>> Is it possible to switch off the GC entirely in D? Can the GC be
>>> switched off completely - including within phobos?
>>
>> import core.memory;
>> GC.disable();
>>
>> However, most D code - including the runtime and standard library -
>> assume that a GC is present, and thus may leak memory.
>
> Guess that answers the question; even if I avoid the GC in my own code and
> disable it as you say, then the runtime and standard library will leak -
> rendering the whole thing as not-an-option.
>
> So I'll either have to not use the runtime+standard libraries and
> implement all I'd need myself without GC or else stick to C++. The latter
> would be a pity because I really like D, but then in C++ I have full
> control and the performance is always good.
>
> In my very simple test, the GC version of my program ran more than twice
> slower than the non GC version. I just cannot accept that kind of
> performance penalty.
>
> Thanks.
>


D's GC is not as good as some other system programming languages like Oberon or Active Oberon, just to cite two examples from many.

However, does the current performance really impact the type of applications you are writing?

I'm asking because I always found the C and C++ communities always care
too much about micro optimizations in cases it does not matter. Coming from a polyglot background I never managed to grok that.

However there are cases where every byte and every ms matter, in those cases you are still better with C, C++ and Fortran.

--
Paulo

On 2013-04-06 06:16, Adrian Mercieca wrote:
> Hi,
>
> Is it possible to switch off the GC entirely in D?
> Can the GC be switched off completely - including within phobos?
>
> What I am looking for is absolute control over memory management.
> I've done some tests with GC on and GC off and the performance with GC is
> not good enough for my requirements.

There's GC free fork of Phobos and druntime floating around at github. Links at the bottom:

http://3d.benjamin-thaut.de/?p=20

-- 
/Jacob Carlborg

Peter Alexander:

> I also use a modified druntime that prints callstacks when a GC allocation occurs, so I know if it happens by accident.

Is it possible to write a patch to activate those prints with a compiler switch?

Bye,
bearophile

On Saturday, 6 April 2013 at 08:01:09 UTC, Adrian Mercieca wrote:
>
> In my very simple test, the GC version of my program ran more than twice
> slower than the non GC version. I just cannot accept that kind of
> performance penalty.
>
> Thanks.

I have ran into similar problems with D and understand what your are looking for, so far the only solution is to change the way you write your code. Automated memory management has pros and cons, you are witnessing the cons and I don't know if a better GC can really solve all of the cons.

In my case I have been able to mostly get around the problem by strategically disabling the GC during active memory allocations, and then re-enabling when all or most of the allocations are completed. In effect I'm doing manual memory management all over again because the automated version fails to do a good enough job. Using this technique I've been able to get near C++ performance speeds.

Part of the problem is that the GC implementation is simply not suitable for performance code and lacks fine tuning abilities (that I'm aware of). Without a decent brain, it does stupid things, so when you have a lot of allocations going on but no deallocations, the GC seems to be running needlessly slowing down the application by as much as 3x.

--rt

On Saturday, 6 April 2013 at 11:01:09 UTC, bearophile wrote:
> Peter Alexander:
>
>> I also use a modified druntime that prints callstacks when a GC allocation occurs, so I know if it happens by accident.
>
> Is it possible to write a patch to activate those prints with a compiler switch?

Yes, but I don't have time to do that right now.