John Carmack applauds D's pure attribute

[Andrew Wiley]

On Sat, Feb 25, 2012 at 4:29 PM, Paulo Pinto <pjmlp at progtools.org> wrote:
> Am 25.02.2012 23:17, schrieb Peter Alexander:
>
>> On Saturday, 25 February 2012 at 22:08:31 UTC, 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.
>>
>>
>> If you require realtime performance then you don't use either the GC or
>> malloc/free. You allocate blocks up front and use those when you need
>> consistent high performance.
>>
>> It doesn't matter how optimised the GC is. The eventual collection is
>> inevitable and if it takes anything more than a small fraction of a
>> second then it will be too slow for realtime use.
>>
>
> There are GC realtime algorithms, which are actually in use, in systems
> like the French Ground Master 400 missile radar system.
>
> There is no more realtime than that. I surely would not like that such
> systems had a pause the world GC.
>

Can you give any description of how that is done (or any relevant
papers), and how it can be made to function reasonably on low end
consumer hardware and standard operating systems? Without that, your
example is irrelevant.
Azul has already shown that realtime non-pause GC is certainly
possible, but only with massive servers, lots of CPUs, and large
kernel modifications.

And, as far as I'm aware, that still didn't solve the generally
memory-hungry behaviors of the JVM.