John Carmack applauds D's pure attribute

[Brad Anderson]

On Tue, Mar 6, 2012 at 5:27 AM, Manu <turkeyman at gmail.com> wrote:

> 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.
>
>
Many STL implementers have abandoned COW (MSVC/Dinkumware, Clang's libc++,
STLPort) and are instead using short-string-optimization.  Reference
counted strings are seen as an anti-optimization in multithreaded code
(especially since rvalue references were added making SSO even faster). [1]


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

That's certainly true, from what I hear, in the games industry but STL is
heavily used outside of games.

Regards,
Brad Anderson

[1] http://www.gotw.ca/publications/optimizations.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120306/92b8a56c/attachment.html>