Inherent code performance advantages of D over C?

[Maxim Fomin]

On Friday, 6 December 2013 at 23:19:22 UTC, Walter Bright wrote:
> You can write D code in "C style" and you'll get C results. To 
> get performance advantages from D code, you'll need to write in 
> a structurally different way (as Andrei pointed out).
>
> Looking through Phobos, there is a lot of code that is not 
> written to take advantage of D's strengths. An apt one 
> discussed here recently is the std.path.buildPath, which is 
> written in "C style", as in allocating memory for its result.
>
> A structural D style version would accept a range for its 
> output, and the range need not allocate memory. This would be 
> fundamentally faster than the typical C approach.
>
> This pattern is repeated a lot in Phobos code.
>
>
>> I believe that most of your points are either insignificant 
>> (like array length -
>> it is carried together with pointer almost everywhere in C)
>
> I see a lot of C code that does strlen() over and over. I think 
> Tango's XML parser showed what can be done in D versus any 
> known C implementation. It took maximal advantage of D's 
> slicing abilities to avoid copying.
>
> Dmitry's regex also showed huge gains over C regex 
> implementations.

This C code is easy to fix. Unlike in D there is no way to fix 
constant gc allocations and if gc is disabled, you say good buy 
to: classes, interfaces, exceptions, dynamic arrays, delegates, 
lambdas, AA arrays, etc.

By the way, if you mentioned strlen(), lets compare printf() and 
writeln().

>> or provide some marginal advantage.
>
> Even a marginal advantage is a counter example to the claim 
> "there is no way proper C code can be slower than those 
> languages."

But summing this issues altogether makes D code cannot compete 
with C code.

>> Such advantages are offset by:
>>
>> - huge runtime library
>
> C has a huge runtime library, too, it's just that you normally 
> don't notice it because it's not statically linked in. Be that 
> as it may, 2.064 substantially reduced the size of "hello 
> world" programs.
>
>> - constant runtime lib invocation and allocation stuff on heap
>
> This is, as I mentioned, a problem with writing C style code in 
> Phobos.

is it a C style?

T[] data = [T, T, T];

or this:

T data;
auto dg = { return data; }

>> - horrible mangling (see
>> http://forum.dlang.org/thread/mailman.207.1369611513.13711.digitalmars-d@puremagic.com
>> examples from hall of D mangling, mangling is so big, that 
>> forum software goes
>> astray)
>
> Long mangling is not an inherent language characteristic, as 
> that thread suggests improvements.

But this is flaw in implementation. Language and its advantages 
are dead without implementation.

And again, notice that you are speaking about 'hypothetical 
advantages' (language advantages) which implies two things:
1) current efficiency is worse when comparing with some benchmark
2) despite many years of development, community failed to realize 
these advantages.

This makes me think that probably there is another reason of why 
code is less efficient, for example fundamental characteristics 
of the language make him hard to be quick. This is not bad per 
se, but saying that language code can be faster than C, taking 
into account some many problems with D, looks like advertisement, 
rather then technical comparison.