On 2012-03-06 17:31, Sean Kelly wrote:
On Mar 6, 2012, at 4:27 AM, Manu <turkey...@gmail.com
<mailto:turkey...@gmail.com>> 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
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.
I have not seen any evidence that Tango would be less safe than Phobos.
Tango uses buffers to let the user optionally pre-allocate buffers. But
if the user doesn't, or the buffer is too small, Tango will allocate the
buffer.
--
/Jacob Carlborg
