John Carmack applauds D's pure attribute

[Sean Cavanaugh]

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.