John Carmack applauds D's pure attribute

[Paulo Pinto]

Am 25.02.2012 23:40, schrieb 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.

Sure.

http://www.militaryaerospace.com/articles/2009/03/thales-chooses-aonix-perc-virtual-machine-software-for-ballistic-missile-radar.html

http://www.atego.com/products/aonix-perc-raven/

--
Paulo