On 26 February 2012 00:55, Walter Bright <newshound2@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.