Inherent code performance advantages of D over C?

[H. S. Teoh]

On Wed, Dec 11, 2013 at 01:33:24AM +0100, Sean Kelly wrote:
> On Wednesday, 11 December 2013 at 00:19:50 UTC, H. S. Teoh wrote:
> >On Tue, Dec 10, 2013 at 11:47:47PM +0100, Sean Kelly 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."
> >>
> >>Didn't Bjarne cover this in his C++ performance talk at SD West in
> >>2007?  Templates alone can make C++ and D code faster than even
> >>hand-optimized C.  And that doesn't even consider some of the other
> >>points you mentioned.
> >
> >The thing is, what constitutes "proper C" is not well-defined,
> >because since C translates to machine code (as does C++ and D), in
> >theory *everything* has access to the same level of performance --
> >that is, the 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. 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. (And the same can be said for C++ and D: use asm blocks,
> >and you'll beat any "normal" C code, 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.)
> 
> Bjarne's point was essentially that templates allow code to be
> inlined to a ridiculous degree.  C code simply can't compete with
> that and still be maintainable.  I suppose you could expand that to
> mean any inlineable code rather than just templates, but the same
> assertion holds.
> 
> I don't think it makes sense to consider the scenario where the "C
> code" is purpose built assembly code because that says nothing about
> the language itself.  Nor does it make sense to restrict the
> compared language to "C style code" (whatever that means) because
> any speed advantages would be leveraging language features or
> conventions not present in idiomatic C.
> 
> For example, I've posted benchmarks of a JSON parser here before
> that I wrote in C and it's considerably faster than anything I've
> seen done in D.  Does that mean that C is faster than D?  Absolutely
> not.  I could recompile the same code in D and have it be just as
> fast as the C version.  The more interesting issue is how easy that
> problem was to solve in each language, and which is more
> maintainable.

Right, that was what I was getting at.

And I think on that count, D trumps C because idiomatic D is both of
comparable performance *and* more maintainable, whereas highly-optimized
C is unreadable.  Not to mention D is easier to write (and write
*correctly* -- and again I'm reminded of Milewski's article about how
the naïve way to write C++, which I think also applies to C, is more
often than not the wrong way, and the right way is very convoluted and
unnatural).


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis