John Carmack applauds D's pure attribute

[Manu]

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


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.



> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120306/8dbf0f68/attachment-0001.html>