Inherent code performance advantages of D over C?

[John Colvin]

On Sunday, 8 December 2013 at 10:13:58 UTC, Araq wrote:
> On Friday, 6 December 2013 at 22:20:19 UTC, Walter Bright wrote:
>>
>> "there is no way proper C code can be slower than those 
>> languages."
>>
>>  -- 
>> http://www.reddit.com/r/programming/comments/1s5ze3/benchmarking_d_vs_go_vs_erlang_vs_c_for_mqtt/cduwwoy
>>
>> comes up now and then. I think it's incorrect, D has many 
>> inherent advantages in generating code over C:
>>
>> 1. D knows when data is immutable. C has to always make worst 
>> case assumptions, and assume indirectly accessed data mutates.
>>
>> 2. D knows when functions are pure. C has to make worst case 
>> assumptions.
>>
>> 3. Function inlining has generally been shown to be of 
>> tremendous value in optimization. D has access to all the 
>> source code in the program, or at least as much as you're 
>> willing to show it, and can inline across modules. C cannot 
>> inline functions unless they appear in the same module or in 
>> .h files. It's a rare practice to push many functions into .h 
>> files. Of course, there are now linkers that can do whole 
>> program optimization for C, but those are kind of herculean 
>> efforts to work around that C limitation of being able to see 
>> only one module at a time.
>>
>> 4. C strings are 0-terminated, D strings have a length 
>> property. The former has major negative performance 
>> consequences:
>>
>>    a. lots of strlen()'s are necessary
>>
>>    b. using substrings usually requires a malloc/copy/free 
>> sequence
>>
>> 5. CTFE can push a lot of computation to compile time rather 
>> than run time. This has had spectacular positive performance 
>> consequences for things like regex. C has no CTFE ability.
>>
>> 6. D's array slicing coupled with GC means that many 
>> malloc/copy/free's normally done in C are unnecessary in D.
>>
>> 7. D's "final switch" enables more efficient switch code 
>> generation, because the default doesn't have to be considered.
>

> coding conventions (4,5,6) (always pass a (char*, len) pair 
> around for efficient slicing).

How does a coding convention allow you to create a 
high-performance regex engine at compile time? How does it allow 
you to do pretty much any of what CTFE can do?

> Interestingly, things that are encouraged in Ada (this is an 
> array of integers of range 0..30, see value range propagation) 
> are much harder to recompute with whole program optimization 
> and D lacks them.

Agreed.