John Carmack applauds D's pure attribute
Dmitry Olshansky
dmitry.olsh at gmail.com
Tue Mar 6 05:13:56 PST 2012
On 06.03.2012 16:27, 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
> 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
you mean like new[] ? That's just gloried allocation. STL vector is a
dynamic array of C++ and it's being used a lot.
the explicit allocation/clean up implies complexity, one will
> always use the stack,
or a fixed array where they can get away with it
Still possible
> Slicing,
Nope
concatenation, etc performs bucket loads of implicit GC
> allocations
It sure does, like it does without GC with reallocs and refcounting.
> 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
It's just most of CRT has incredibly bad usability, partly because it
lack _any_ notion of allocators. And policy of using statically
allocated shared data like in localtime, srand etc. shown remarkably bad
M-T scalability.
> 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
like COW?
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.
I've seen some, and sometimes memory corruption when people hesitated to
copy even when they *do* need to pass a copy.
>
> 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?
Like everybody? Though with c++11 move semantics a unique_ptr is going
to lessen it's widespread use. And there are ways to spend less then 2
proper memory allocations per shared_ptr, like keeping special block
allocator for ref-counters.
More importantly smart pointers are here to stay in C++.
Talking about the stl is misleading... an
> overwhelming number of C/C++ programmers avoid the stl like the plague
> (for these exact reasons).
Instead of using it properly. It has a fair share of failures but it's
not that bad.
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?
--
Dmitry Olshansky
More information about the Digitalmars-d
mailing list