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
