John Carmack applauds D's pure attribute

[deadalnix]

Le 26/02/2012 08:48, Paulo Pinto a écrit :
> Am 26.02.2012 00:45, schrieb Andrew Wiley:
>> On Sat, Feb 25, 2012 at 5:01 PM, Paulo Pinto<pjmlp at progtools.org> wrote:
>>> 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/
>>
>> Neither of those links have any information on how this actually
>> works. In fact, the docs on Atego's site pretty much state that their
>> JVM is highly specialized and requires programmers to follow very
>> different rules from typical Java, which makes this technology look
>> less and less viable for general usage.
>>
>> I don't see how this example is relevant for D. I can't find any
>> details on the system you're mentioning, but assuming they developed
>> something similar to Azul, the fundamental problem is that D has to
>> target platforms in general use, not highly specialized server
>> environments with modified kernels and highly parallel hardware. Until
>> such environments come into general use (assuming they do at all; Azul
>> seems to be having trouble getting their virtual memory manipulation
>> techniques merged into the Linux kernel), D can't make use of them,
>> and we're right back to saying that GCs have unacceptably long pause
>> times for realtime applications.
>
> In Java's case they are following the Java's specification for real time
> applications.
>
> http://java.sun.com/javase/technologies/realtime/index.jsp
>
> I did not mention any specific algorithm, because like most companies, I
> am sure Atego patents most of it.
>
> Still a quick search in Google reveals a few papers:
>
> http://research.microsoft.com/apps/video/dl.aspx?id=103698&l=i
>
> http://www.cs.cmu.edu/~spoons/gc/vee05.pdf
>
> http://domino.research.ibm.com/comm/research_people.nsf/pages/bacon.presentations.html/$FILE/Bacon05BravelyTalk.ppt
>
>
> http://www.cs.technion.ac.il/~erez/Papers/real-time-pldi.pdf
>
> http://www.cs.purdue.edu/homes/lziarek/pldi10.pdf
>
> I know GC use is a bit of a religious debate but C++ was the very last
> systems programming language without automatic memory management. And
> even C++ has got some form in C++11.
>
> At least in the desktop area, in a decade from now, most likely system
> programming in desktop OS will either make use of reference counting
> (WinRT or ARC), or it will use a GC (similar to Spin, Inferno,
> Singularity, Oberon).
>
> This is how I see the trend going, but hey, I am just a simple person
> and I get to be wrong lots of time.
>
> --
> Paulo

Thank you for the documentation. The more I know about GC, the more I 
think that user should be able to choose which GC they want.