bearophile wrote:
Mike S:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
It's a nice read. I don't see them switching to D soon. If you whisper them
that D is based on a GC they will run away screaming :-)
Bye,
bearophile
Hah...well, there's a reason I'm still just looking into D rather than
diving in headfirst! :p Actually though, I do believe the needs of game
programmers should be taken seriously while considering D's evolution:
Right now, D hasn't completely found its niche, but it seems to position
itself as a sane successor to C++ for systems-level programming. As it
stands, I believe there are only two major kinds of programmers who
still use C++, and those are game programmers and masochists. ;) Odds
are, D won't be replacing C anytime soon for operating system kernels
and such. It's too low-level for scripting tasks, and most website
designers and non-real-time applications programmers use higher-level
languages already (C#, Python, PHP...shudder...etc.), and they're
unlikely to go back. I think D will eventually be used for writing
other heavy-duty non-OS frameworks and software systems, but if it's
really going to become the successor to C++, it's going to have to
absorb most of C++'s user base...and that includes game programmers.
You're right that the garbage collector is a major issue - probably the
biggest one inherent to the language design - but I haven't determined
it's a dealbreaker, at least not yet. After all, D also allows manual
memory management, and freeing memory early apparently helps speed
things up anyway
(http://stackoverflow.com/questions/472133/turning-off-the-d-garbage-collector).
That part helps ensure control over how much memory is used/available,
and the only other issue with the garbage collector is reconciling its
running time with the soft real-time constraint that games have to
satisfy. I can think of a few tactics which should help here:
1.) In addition to permitting better reasoning about memory
allocations, freeing most memory manually should reduce the load on the
garbage collector and reduce its runtime, right?
2.) On the simulation side of the game engine, I believe a constant
timestep promotes a more robust design, and that means some frames
(relatively idle ones) will have plenty of CPU time left over. If you
can explicitly call the garbage collector to make it run during those
times instead of at nondeterministic times (can you?), you can maintain
a smooth framerate without any GC-induced spikes.
3.) Can user code execute simultaneously with the GC in other threads
(on other cores), or does the GC halt the entire program for safety
reasons? Assuming simultaneous threaded execution is permitted, it
would also dramatically reduce the GC's impact on multi-core systems.
Assuming these strategies work, the garbage collector by itself
shouldn't be a showstopper. In the case of dynamic arrays, resizing
capacity deterministically is one of those small things that would be
really helpful to anal game programmers, and it probably wouldn't hurt
anyone else, either. Plus, it's easier to implement than "smart
nondeterministic" resizing anyway. :)
