On 11/30/2011 09:58 PM, bigsandwich wrote:
Jeff Nowakowski Wrote:
On 11/30/2011 01:38 PM, Walter Bright wrote:
Yes, it is. What I meant by the "large and heavy rock" is the difficulty
of expressing any sort of semantics that are not Java semantics in the
JVM bytecode.
Fair enough.
In C++, one does all the memory management manually.
But in C++ libraries are designed with this in mind. You didn't address
his point: "Unless you want to do all of the memory management yourself,
which pretty much results in not using phobos and most of the cool
features in D."
And isn't the point of D to relieve you of the burden of doing stuff
like memory management? You should read Tim Sweeney's (Gears of War
developer) "The Next Mainstream Programming Language", where the slide
for Gameplay Simulation says, "Usually garbage-collected." I assume by
this he means that for C++ the developers end up writing their own
garbage collector inside the program.
http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
If D could demonstrably solve the problems outlined in these slides,
you'd have a whole industry at your fingertips.
I don't usually post, but "someone is wrong on the internet"
(http://xkcd.com/386/) :)
"Usually garbage collected" in the case of Unreal refers to Unreal Script which
is not C++ at all. Its a language similar to Java that is compiled into bytecode.
Such kind of code could be written in (Safe)D perfectly fine and it
would certainly perform better as well
Most games use allocations schemes for different parts of the game, including
garbage collection. You wouldn't want to use GC in performance critical code
anyway, so it probably doesn't matter that its that slow.
What does matter is having a way to isolate GC to the few libraries where your
willing to pay for it and turn it off for everything else. It would be great
if there was a way to build a static library and just pass a switch that would
make compilation fail if there was GC allocation in the library.
Afaik this is planned.
Other good features if you want to push into game dev:
1) Be able to override allocators (ie new, delete, or whatever they are called
in D now) so that you can allocate out of different heaps.
http://www.d-programming-language.org/class.html#allocators
Andrei wants to deprecate them in favour of std.conv.emplace. I have
already used std.conv.emplace to good effect for some simple custom
class allocators.
Every allocation in my performance sensitive code looks like this:
New!Class(params)
I can then replace the allocator for a whole module by changing one
small alias at the top of the module to quickly test performance of
different allocation schemes on typical workloads.
2) Be able to control when GC occurs (ie every x frames, or in between levels,
or only when there is a lull in the action).
http://www.d-programming-language.org/phobos/core_memory.html
In D, you have full control over the GC. You can disable and enable it,
you can explicitly start a collection and you can even ask it to free as
much of its internal data structures as possible etc. (And there is
still a huge potential for improvements of its implementation! :o))
The quite common claim that you cannot use Phobos without cluttering up
all your code with allocations is just not true. Phobos is not an
Object-oriented class library. There are seldom hidden allocations, and
it is almost always obvious when allocations must happen. The most
useful high-level features of D are compile time features that do not
harm performance (on the contrary).
