GC vs. Manual Memory Management Real World Comparison

[Paulo Pinto]

On Tuesday, 23 October 2012 at 22:31:03 UTC, Rob T wrote:
> On Tuesday, 23 October 2012 at 16:30:41 UTC, Benjamin Thaut 
> wrote:
>> Here a small update:
>>
>> I found a piece of code that did manually slow down the 
>> simulation in case it got to fast. This code never kicked in 
>> with the GC version, because it never reached the margin. The 
>> manual memory managed version however did reach the margin and 
>> was slowed down. With this piece of code removed the manual 
>> memory managed version runs at 5 ms which is 200 FPS and thus 
>> nearly 3 times as fast as the GC collected version.
>>
>> Kind Regards
>> Benjamin Thaut
>
> That's a very significant difference in performance that should 
> not be taken lightly. I don't really see a general solution to 
> the GC problem other than to design things such that a D 
> programmer has a truely practical ability to not use the GC at 
> all and ensure that it does not sneak back in. IMHO I think it 
> was a mistake to assume that D should depend on a GC to the 
> degree that has taken place.
>
> The GC is also the reason why D has a few other significant 
> technical problems not related to performance, such as 
> inability to link D code to C/C++ code if the GC is required on 
> the D side, and inability to build dynamic liraries and runtime 
> loadable plugins that link to the runtime system - the GC 
> apparently does not work correctly in these situatons, although 
> the problem is solvable how this was allowed to happen in the 
> first place is difficult to understand.
>
> I'll be a much more happy D programmer if I could guarantee 
> where and when the GC is used, therefore the GC should be 100% 
> optional in practice, not just in theory.
>
> --rt


Having dealt with systems programming in languages with GC 
(Native Oberon, Modula-3), I wonder how much an optional GC would 
really matter, if D's GC had better performance.

--
Paulo