Inherent code performance advantages of D over C?

[Walter Bright]

On 12/6/2013 11:34 PM, Maxim Fomin wrote:
> On Friday, 6 December 2013 at 23:19:22 UTC, Walter Bright wrote:
>> 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.

No it isn't. Have you tried? I have, it's very hard to retrofit a non-trivial C 
program with carrying around all the string lengths as a separate value. Call 
just about any C library, and you're back again to strlen(). It's even harder to 
get away from strlen() in C++ because it inextricably tied std::string to it.

A lot of capable people worked for decades on C regexen, yet Dmitry blew them 
away with his D version.


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

I think you're way exaggerating. (Note that C has none of those features.)


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

Sure. Feel free.


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

This is simply not true. You might want to look at Don's presentation at 
Dconf2013 where he explains that Sociomantic uses D not for romantic reasons but 
because the performance of it gives a competitive edge.


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

I've worked with a lot of C compilers that had lousy, buggy implementations and 
lousy code generation. I'm being careful here to deal with characteristics of 
the language, not the 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.

There are several D projects which show faster runs than C. If your goal is to 
pragmatically write faster D code than in C, you can do it without too much 
effort. If your goal is to find problem(s) with D, you can certainly do that, too.