John Carmack applauds D's pure attribute

[Timon Gehr]

On 03/06/2012 01:27 PM, Manu wrote:
> On 26 February 2012 00:55, Walter Bright <newshound2 at digitalmars.com
> <mailto: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

If you believe this, why do you raise this issue?

>    It's easy to clean up - you don't have to worry about cleanup
> problems, makes it simpler to use in many situations

GC does not prevent memory leaks, it does not support deterministic 
cleanup, and most implementations perform poorly on certain workloads. 
You were saying?

>    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,

Slicing does never allocate.

> concatenation, etc performs bucket loads of implicit GC
> allocations

a~b

Nothing implicit about that.

The only case where memory allocation is implicit is for closures.


>    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.

IMHO this fear is unjustified. If the library developers are that 
sloppy, chances are that the library is not worth using, even when 
leaving all memory allocation concerns away. (It is likely that you 
aren't the only programmer familiar with some of the issues.)

> 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,

Yes, a function that does not obviously need to allocate shouldn't, and 
if possible there should be alternatives that do not allocate. Do you 
have any particular examples where such a policy would be violated in 
Phobos?

> and ideally, druntime should NEVER allocate if it can help it.
>

+1. What are examples of unnecessary allocations in druntime?

>
>     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

Technically, refcounting is a form of GC.

> 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.

It is impossible to slice a zero-terminated string without copying it in 
the general case and refcounting slices is not trivial.


>
>     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?

Possibly now you are the one who is to provide supporting statistics.

> If you're not performance oriented, then who cares about the GC either?

There is a difference between not performance oriented and performance 
agnostic. Probably everyone cares about performance to some extent.