On 2/25/2012 4:08 PM, Paulo Pinto wrote:
Am 25.02.2012 21:26, schrieb Peter Alexander:
On Saturday, 25 February 2012 at 20:13:42 UTC, so wrote:
On Saturday, 25 February 2012 at 18:47:12 UTC, Nick Sabalausky wrote:
Interesting. I wish he'd elaborate on why it's not an option for his
daily
work.
Not the design but the implementation, memory management would be the
first.
Memory management is not a problem. You can manage memory just as easily
in D as you can in C or C++. Just don't use global new, which they'll
already be doing.
I couldn't agree more.
The GC issue comes around often, but I personally think that the main
issue is that the GC needs to be optimized, not that manual memory
management is required.
Most standard compiler malloc()/free() implementations are actually
slower than most advanced GC algorithms.
Games do basically everything in 33.3 or 16.6 ms intervals (30 or 60 fps
respectively). 20fps and lower is doable but the input gets extra-laggy
very easily, and it is visually choppy.
Ideally GC needs to run in a real-time manner, say periodically every 10
or 20 seconds and taking at most 10ms. Continuously would be better,
something like 1-2ms of overhead spread out over 16 or 32 ms. Also, a
periodic GC that freezes everything needs to run at a
predictable/controllable time, so you can do things like skip AI updates
for that frame and keep the frame from being 48ms or worse.
These time constraints are going to limit the heap size of a GC heap to
the slower of speed of memory/computation, until the GC can be made into
some variety of a real-time collector. This is less of a problem for
games, because you can always allocate non-gc memory with malloc/free or
store your textures and meshes exclusively in video memory as d3d/opengl
resources.
The fact malloc/free and the overhead of refcounting takes longer is
largely meaningless, because the cost is spread out. If the perf of
malloc/free is a problem you can always make more heaps, as the main
cost is usually lock contention.
The STL containers are pretty much unusable due to how much memory they
waste, how many allocations they require, and the inability to replace
their allocators in any meaningful way that allows you to used fixed
size block allocators. Hashes for instance require multiple different
kinds of allocations but they are forced to all go through the same
allocator. Also, the STL containers tend to allocate huge amounts of
slack that is hard to get rid of.
Type traits and algorithms are about the only usable parts of the STL.
