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