John Carmack applauds D's pure attribute

Andrew Wiley wiley.andrew.j at gmail.com
Sat Feb 25 14:36:43 PST 2012


On Sat, Feb 25, 2012 at 4:08 PM, Paulo Pinto <pjmlp at progtools.org> 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.

That's not the issue here. The issue is that when your game is
required to render at 60fps, you've got 16.67ms for each frame and no
time for 100ms+ GC cycle. In this environment, it's mostly irrelevant
that you'll spend more time total in malloc than you would have spent
in the GC because you can only spare the time in small chunks, not
large ones.

One simple solution is to avoid all dynamic allocation, but as a few
mostly unanswered NG posts have shown, the compiler is currently
implicitly generating dynamic allocations in a few places, and there's
no simple way to track them down or do anything about them.


More information about the Digitalmars-d mailing list