John Carmack applauds D's pure attribute

Jacob Carlborg doob at me.com
Tue Mar 6 09:57:16 PST 2012


On 2012-03-06 17:31, Sean Kelly wrote:
> On Mar 6, 2012, at 4:27 AM, Manu <turkeyman at gmail.com
> <mailto:turkeyman at gmail.com>> 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 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


More information about the Digitalmars-d mailing list