Inherent code performance advantages of D over C?

[Dmitry Olshansky]

07-Dec-2013 13:32, Johannes Pfau пишет:
> Am Sat, 07 Dec 2013 03:12:02 +0400
> schrieb Dmitry Olshansky <dmitry.olsh at gmail.com>:
>
>> 07-Dec-2013 02:20, Walter Bright пишет:
>>>
>>> "there is no way proper C code can be slower than those languages."
>>
>>> 3. Function inlining has generally been shown to be of tremendous
>>> value in optimization. D has access to all the source code in the
>>> program, or at least as much as you're willing to show it, and can
>>> inline across modules.
>>
>> Uh-oh. I'd avoid advertising this particular point until after a
>> critical bug is fixed:
>> https://d.puremagic.com/issues/show_bug.cgi?id=10985
>> Applies to all 3 compilers.
>>
>> Otherwise - it's spot on. D has many ways to be typically "faster
>> then Cee" ;)
>>
>
> But cross-module inlining can't be done if you have shared libraries
> cause you can not know if the other module is in a shared library right?
>

I've no idea how would compiler do inlining of a shared library 
internals. I believe it can inline everything in the same library that 
is not exported, right? (Is that your point (1) ?)

> If you inlined such code it wouldn't get updated if the shared library
> was updated and you'd have two versions of the code around...

Then some critical stuff simply must not be called via shared library 
and better be translated to ... 0-argument templates.

Use cases: std.ascii and not only that. Checking ASCII isAlpha as a 
_function call_ is madness.

>
> I see only 2 solution to avoid this:
>
> (1) If the source files are compiled at once it's safe to assume they
>      must be part of the same library and inlining is safe

> (2) The linker of course knows how objects fit together, so LTO.
>


-- 
Dmitry Olshansky