Inherent code performance advantages of D over C?

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Wednesday, 11 December 2013 at 00:19:50 UTC, H. S. Teoh wrote:
> hardware. So arguably, no matter what code fragment you may  
> present in
> C++ or D, there's always a corresponding C code fragment that 
> performs
> equally fast or faster.

Yes, but the unix/C-way is to have many simple programs that work 
together to make complex systems. C is meant to be used with 
makefiles and source-generating tools such as Lex, Ragel and even 
the C-preprocessor. C++ and D claim to be self-sufficient. C was 
never meant to be, it was meant to be part of the unix 
eco-system. What you do with templates and and 
compile-time-expressions in C++/D is what you do with the 
ecosystem of tools in C. Therefore a comparison between C and 
C++/D should include that C-ecosystem. If people don't like 
sourcecode-generating tools, fine, but that is the unix/C way of 
programming and it should be included when assessing the power of 
C versus C++/D (and their template libraries).

> But that obscures the fact that said C  code
> fragment may be written in an unmanageably convoluted style 
> that no one in their right mind would actually use in practice.

Well, C-programmers do, if they have tools that generate that 
convoluted style from a readable input file (like lex).

> but that proves nothing since the whole issue is writing  
> *idiomatic* C
> vs. *idiomatic* D, not writing things in an unnatural way just 
> so you can lay claim to the title of best performance.)

Exactly, and idiomatic C is to use source-generating tools. Just 
about all medium to large size C projects use such tools that go 
beyond the C-preprocessor (which conceptually is a separate tool 
that is optional in theory).

Anyway, one cannot discuss performance without discussing the 
target. Much of the stuff in C makes sense on memory-constrained 
hardware, even C-strings are great when you want to conserve 
memory and have hardware-support for 0-guarded strings 
(string-instructions that will stop on 0).  And, JITed regexps 
won't work on mobile platforms or platforms that require signed 
code.

We are now getting a new range of memory constrained hardware, 
transputer-like processsors with many simple cores with fast 
local memory and a saturated link to main memory. So the 
memory-efficent way of getting performance is still highly 
relevant.

Performance is always contextual. E.g. I think OpenCL is just an 
intermediate step to getting performance, compilers will soon 
have to emit co-processor friendly code automagically and 
languages will have to provide constructs that makes that happen 
in the most efficient way. So if C is out-dated then so are all 
other languages in current use… ;-)

O.