Inherent code performance advantages of D over C?

[Dicebot]

On Thursday, 12 December 2013 at 11:42:12 UTC, Manu wrote:
> I've built a C codebase from the ground over the course of a 
> decade with
> ~25 programmers.
> It takes discipline, and a certainly sense of simplicity in 
> your solutions.

It may work if you can afford to guarantee certain level of 
competence of majority of programmers in the team but I think is 
exception in practice, not rule. Also I had a bit larger teams in 
mind as it tends to happen with enterprise C :)

> and what is more valuable than a
> programmers time?

At some point new servers + server maintenance becomes more 
expensive than programmers time. Much more expensive.

> I still consider C a macro assembler... I can easily (and 
> usually do)
> visualise the asm output I expect the compiler to produce while 
> I'm coding.
> If I'm writing performance intensive code, I am constantly 
> disassembling
> and checking that the compiler is producing the code I am 
> expecting. This
> feels normal to me.

Did you use many different compilers? I am afraid that doing that 
on a common basis is feat of strength beyond my imagination :)

> What would you want inline assembly for in D? Inline assembly 
> is almost
> always a mistake, unless you're writing a driver.

I can't find code Adam used to provide minimal d runtime stubs to 
compile C-like programs but he was forced to use in-line assembly 
there in few cases. Can't remember details, sorry.

And of course I am speaking about drivers / kernels / barebone. I 
can't imagine any other domain where using C is still absolutely 
necessary for practical reasons.

> You can't possibly
> schedule code better than the compiler.
> ...

I am not implying that one should do anything by hand because 
compiler is bad at it. I have not actually used inline assembly 
with C even a single time in my life. That wasn't about it.