John Carmack applauds D's pure attribute

[Jacob Carlborg]

On 2012-02-25 23:36, Andrew Wiley wrote:
> 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.

You can remove the GC and you'll get a linker error when its used. Not 
the best way to track them down but it works.

-- 
/Jacob Carlborg