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