Inherent code performance advantages of D over C?

[Walter Bright]

On 12/6/2013 3:02 PM, Maxim Fomin wrote:
> What surprises me most is claim that D can 'hypothetically' generate more
> efficient code comparing with C, especially taking into account current
> situation with code generation and optimization.
>
> The claim about inherent advantages implies that code generation is not good
> now. If it can be so efficient, why it is not the case? And if in practice it is
> worse, than who cares that 'in theory' code can be better?

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.

> 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."

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

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

> - phobos snowball - one invocation of some function in standard library leads to
> dozens template instantiations and invocations of pretty much stuff

True enough, but does that lead to non-performant code? 2.064 cuts that down 
quite a bit anyway, and I think we can make more improvements in this regard.