Inherent code performance advantages of D over C?

Walter Bright newshound2 at digitalmars.com
Mon Dec 9 11:19:46 PST 2013


On 12/9/2013 6:24 AM, Araq wrote:
> ("When in doubt, assume it modifies this location.")

And it's usually in doubt, often enough to make that optimization a pipe dream.


>> (2) is impractical because there's no way for the programmer to detect if his
>> call stack is pure or not, so he can't reasonably fix it to make it pure.
>
> Well look at the subject: "inherent" vs "practical".

When you're dealing with real code, it might as well be inherent. Your argument 
boils down to "a sufficiently smart compiler" which will never exist and 
"programmers going to superhuman lengths" which never happens to try and justify 
that C is the fastest.

You might as well claim that a cyclist could bicycle from Seattle to Portland 
and average 30 mph, because he can hit 30 in a sprint.


>> (3) does require whole program analysis, which is done (as I said) by the
>> linker, and is not normally done. Will gcc/ld do it? Nope. (It's not so trivial.)
> Both GCC and LLVM can perform link time optimizations.

Inlining across source files?


>> (4) just try retrofitting an existing C program to do this. I have. You'll
>> give it up soon :-)
> Again -- the subject is "inherent code performance advantages".

It's inherent, as C does not support this, everything about C works against you 
if you try it, and those who try are punished. You can't even use much of the 
standard library if you try this.



More information about the Digitalmars-d mailing list