On Monday, 6 March 2017 at 15:40:54 UTC, Rico Decho wrote:
If this isn't a perfect example of D's marketing problem I
don't know what is. Someone who likes D and takes the time to
write on the forum yet thinks the GC will randomly run no
matter what.
To make it abundantly clear: I'm not bashing on you in the
slightest, Rico Decho. I'm just pointing out that there's a
clear problem here in that we can't expect to convert e.g. C++
game developers who have never written a line of D before if
we haven't even managed to educate the community yet.
Unfortunately, I have no ideas on how to remedy the situation.
I also don't know how to get people to stop believing that C
is magically fast either, which I think is a similar
perception problem.
Atila
Actually it's written in the documentation.
That's true and was pointed out to me on Twitter by a C++ dev. I
don't know what's up with that but I'm _pretty_ sure it doesn't
happen in practice, but only somebody who knows the GC
implementation well can comment I guess.
If I remember well the garbage collection could be triggered
during any allocation, for instance when concatenating some
displayed text, and freeze all threads until the garbage
collection is done.
Right. So slap `@nogc` on whatever is in the game loop and that's
guaranteed to not happen.
In my opinion, the problem is D's GC implementation.
This is also a problem, yes.
For instance, Nim uses a soft (realtime) GC, which is why Nim's
author himself has made the Urho3D wrapper :)
With this approach, no need to disable the GC and make manual
allocations to avoid that the GC freezes all threads.
Instead you simply use all the standard libraries as normally,
while still try to avoid allocating too much stuff during the
rendering of course.
During the render loop, in Nim you occasionally call the GC
with an numeric argument telling how much milliseconds it is
allowed to use in the worst case.
That's pretty cool.
Atila
