John Carmack applauds D's pure attribute

[Sean Kelly]

On Mar 6, 2012, at 4:27 AM, Manu <turkeyman at gmail.com> wrote:

> On 26 February 2012 00:55, Walter Bright <newshound2 at digitalmars.com> wrote:
> On 2/25/2012 2:08 PM, Paulo Pinto wrote:
> Most standard compiler malloc()/free() implementations are actually slower than
> most advanced GC algorithms.
> 
> Most straight up GC vs malloc/free benchmarks miss something crucial. A GC allows one to do substantially *fewer* allocations. It's a lot faster to not allocate than to allocate.
> 
> Do you really think that's true? Are there any statistics to support that?
> I'm extremely sceptical of this claim.
> 
> I would have surely thought using a GC leads to a significant increase in allocations for a few reasons:
>   It's easy to allocate, ie, nothing to discourage you
>   It's easy to clean up - you don't have to worry about cleanup problems, makes it simpler to use in many situations
>   Dynamic arrays are easy - many C++ users will avoid dynamic arrays because the explicit allocation/clean up implies complexity, one will always use the stack, or a fixed array where they can get away with it
>   Slicing, concatenation, etc performs bucket loads of implicit GC allocations

Concatenation anyway. 


>   Strings... - C coders who reject the stl will almost always have a separate string heap with very particular allocation patterns, and almost always refcounted
>   Phobos/druntine allocate liberally - the CRT almost never allocates
> 
> This is my single biggest fear in D. I have explicit control within my own code, but I wonder if many D libraries will be sloppy and over-allocate all over the place, and be generally unusable in many applications.
> If D is another language like C where the majority of libraries (including the standard libraries I fear) are unusable in various contexts, then that kinda defeats the purpose. D's module system is one of its biggest selling points.
> 
> I think there should be strict phobos allocation policies, and ideally, druntime should NEVER allocate if it can help it.

druntime already avoids allocations whenever possible. For example, core.demangle generates it's output in-place in a user-supplied buffer.

Regarding allocations in general, it's a matter of design philosophy. Tango, for example, basically never implicitly allocates. Phobos does. I'd say that Phobos is safer to program against and easier to use, but Tango affords more control for the discerning programmer. Personally, I'd like to see fewer implicit allocations in Phobos, but I think that ship has sailed. 


> Consider C strings. You need to keep track of ownership of it. That often means creating extra copies, rather than sharing a single copy.
> 
> Rubbish, strings are almost always either refcounted or on the stack for dynamic strings, or have fixed memory allocated within structures. I don't think I've ever seen someone duplicating strings into separate allocations liberally.

I think the C standard library was designed with the intent that strings would be duplicated during processing, similar to D 's native string operations. It's true that people often use static buffers instead, but this has also been an enormous source of program bugs. Buffer overflow attacks wouldn't exist in C if people didn't do this. That said, I do it too. And I'll readily say that working with strings this way is a huge pain in the ass. It's just has more predictable performance. 


> Enter C++'s shared_ptr. But that works by, for each object, allocating a *second* chunk of memory to hold the reference count. Right off the bat, you've got twice as many allocations & frees with shared_ptr than a GC would have.
> 
> Who actually uses shared_ptr? Talking about the stl is misleading... an overwhelming number of C/C++ programmers avoid the stl like the plague (for these exact reasons). Performance oriented programmers rarely use STL out of the box, and that's what we're talking about here right? If you're not performance oriented, then who cares about the GC either?

I've used it extensively. Managing memory ownership is one of the most complicated tasks in a C/C++ app, and in C++ this often means choosing the appropriate pointer type for the job--auto_ptr for transferral of ownership, shared_ptr, etc. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120306/6fb22811/attachment-0001.html>